^flD-fll34  884  INTER-SERVICE/flGENCV  flUTOHflTED  HESSflGE  PROCESSING 
^  EXCHANGE  PROGRAM  FUNCTI.  .  (U)  DEFENSE  COMMUNICATIONS 

AGENCV  ARLINGTON  VA  81  NOV  83 


UNCLASSIFIED 


F/G  17/2 


± 

DEFENSE  COMMUNICATIONS  AGENCY 


IN'l'KUSKH  VICE,  agency 
Al'TOMA'IEl)  MESSAGE  PHOCESSING 

exchange  program 

FUNCTIONAL 

REQUIREMENTS 

DESCRIPTION 

AND 

INTERFACE 

CONTROL 

DOCUMENT 

(  Will!  (.RU^'S  REMKhNCC  f’ATRlCLS  ) 

f  ijP  PMR!  ;r  pi  ha. 

■  .fp;8'  . '  PI  MN.  irpi  uu 


)  I (A  -  '  V 

■  sl.-i; 


A  >';ir  ICA  '  lO  1 


REPORT  DOCUMtr.'l  AflON  f'AGF 

r>  "  m  r  •C  ":  1  V*'  M  AF.i'  If 


DEFENSE  COMMUNICATIONS  AGENCY 


FUNCTIONAL 

REQUIREMENTS 

DESCRIPTION 


Acoosnitrn  For 


Inter-Servic;*  Ager.cv  A'^tcnatea  Ar'CGssiOvq  ty.cnar.'.s 

U-s;,  ,a:-;-C;  " 

rUACTi C'.‘(Al  R£(^U]R£X£h’/ S  DESC^IPIIlN  iFRD/ 

and 

INTERFACE  CONTROL  DOCUMENT  (ICD) 


Intecrated  AUTODIN'  System  (IAS)  Re'':'ji r-men^-.s  Panel  Cocncination  Shee 


Ccorcir.ation  inaicates  IA5  Requ iremr^nci  Par.el-Tevel  agorovel  of  the 
incorporation  of  all  Serv ice/Agency  cor^tents  to  this  docu'^cot  recei 
to  cate  witr.  tne  exception  tnat  the  fol  iO'.-'inj  sections  of  toe  FRD/; 
have  not  teen  con.pletec  at  this  time: 

Section  20,  I-S/A  AMPE  Message  Form, at  Vslication  { '^^ir 

Section  30,  Security  Appencix 


ilJ  .  .U  fj 


!L!  I 


LtrcNuE  IN  cLlIOHNuc  Ao£ 


)cr  cN-E 


U*<iCr  iVrf  iii  f  OC.*’'V.  f 


nt,e»'-Serv  ice  Aijeiicy  Automated  Messaye  Processing  ExchanL,e 

( r-S/A  AMPE) 


Functional  Requirements  Description  (FRU) 
Section  30.0 


Inteurdted  AUTODIN  System  Keq  u  i  r  eine  fi  t  s  Panel 
Coordination  Sheet 


oordination  indicates  lASRP-level  approval  of  the 
ncorporation  of  all  Ser  v  i  ce/Agency  cominents  to  this  docunient 
-•  0 e  i  V e  J  to  date. 


\ 

NAVY  ~JT  ^ 


/ /V  •,  ,  r  >  f  •! 

N ^TWal  SecuKty  agency 


A 


1-  '  'NTFLl  IG 


it; 


defen^eTUg 


Inter-Service  Agency  Autonated  Message  Processing  Exchange 

(I-S/A  AMPE) 


FUNCTIONAL  STATEMENT  DOCUMENT  (FSO) 
APPENDIX  38 

I-S/A  AMPE  MESSAOE  FORMAT  VALIDATION 


Integrated  AUTODIN  Systen  (IAS)  Requirenents  Panel  Coordination  Sheet 


Coordination  indicates  IAS  Requirenents  Panel-level  approval  oC  the 
incorporation  of  all  Service/Agency  requirenents  to  this  docunent. 
Appendix  38  v/ill  also  becone  FRD  (Section  PO)  upon  approval 


PREFACE 


The  Inter-Service/Agency  Automated  Message  Processing  Exchange  (I-S/A 
A^■1PE)  Functional  Requirements  Description  (FRD)  is  an  intermediate  step  in  the 
documentation  and  specification  of  the  requirements  of  Military  Services, 
Defense  Agencies,  joint  Chiefs  of  Staff  and  the  Department  of  Defense  for  a 
common-user  communications  automation  facility  which  will  be  a  follow-on  and 
replacement  of  existing  Service  and  Agency  AMPE  programs  and  the  AUTODIN 
Switching  Centers  (ASCs). 

The  FRD  and  its  companion  Interface  Control  Document  (ICD)  are  an 
outgrowth  of  earlier  documentation;  the  Functional  Statement  Document  (FSD)  in 
three  sections  (Section  I  -  Base  Level,  Section  II  -  ASC  Residual,  and  Section 
III  -  Network  interface).  The  FRD  and  ICD  organize  the  FSD  statements  in  a 
logical,  system-oriented  manner;  expand  and  extrapolate  them  to  provide  the 
basis  for  technical  specifications;  and  fill  in  requirements  (e.g.,  system 
performance  and  sizing)  dictated  by  system  needs. 


The  validated  baseline  for  the  FRD  and  ICD  is  the  three  section  FSD.  When 
validated,  the  FRD  and  ICD  become  the  baseline  for  the  preparation  of  the 
solicitation  package  by  the  Air  Force  Automated  Systems  project  Office,  Gunter 
AFS,  Alabama. 
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1.0  SCOPE 


This  is  tne  futiciional  requireir.ents  cescripticn  for  the 
Inier-Service/^gencv  .-.utomaieo  i-.essage  Processing  Exchange  U-S/A  ^-lPE),  a 
service  processing  elen-ent  of  the  Integrateo  AUTOUIi','  SvsLe.'Ti  (ImS).  Tne  I-S/A 
aMPE  will  perforin  tne  following  Tunctions: 

a.  .‘•■cssage  processing  currently  done  Ly  Service/Agency  (S/A)  eMPEs. 

0.  Tessace  processing  currently  cone  ov  the  nCTO..!,'.  S.vitcninc  Centers 
(ASCs). 

c.  Information  intercnange  between  AUTOOIN  and  Defense  Data  Network 
(DON)  subscriber  communities. 


a.  Secure  information  processing 
information . 

1.01  oasis 

This  document  forms  the  basis  for 
following  I-S/A  AMPE  specifications: 

a.  Type  A  Specification  -  System 
specification  will  state  the  technical 
AMPE  (See  Appendix  I  of  MIL-STO-490) . 


ana  transfer,  to  include  compartmentea 

the  development  ana  preparation  of  the 

Specification.  This  type  of 

ana  mission  requirements  for  the  I-S/A 


b.  Type  B  Specification  -  Development  Specifications.  These 
specifications  will  state  the  requirements  for  the  design  or  engineering 
development  of  the  I-S/A  AMPE.  Two  types  of  these  specifications  will  be 
prepared . 


(1)  Type  B2  -  Critical  Item  Development  Specification  (See  Appendix 
III  of  MIL-STO-490) .  Type  B2  specifications  will  be  prepared  for  I-S/A  AMPE 
items  which  are  engineering  critical  or  logistics  critical. 

(2)  Type  B5  -  Computer  Program  Development  Specification  (See 
Appendix  VI  of  MIL-STD-490) .  This  type  of  specification  will  be  prepared  for 
development  of  the  I-S/A  AMPE  computer  programs,  and  it  will  describe  in 
operational,  functional,  and  mathematical  language  all  the  requirements 
necessary  to  design  and  verify  the  required  computer  programs  in  terms  of 
performance  criteria. 

c.  Type  C  Specification  -  Product  Specifications.  These  specifications 
will  be  applicable  to  I-S/A  AMPE  items  which  are  functional  (performance) 
requirements  or  fabrication  (detailed  design)  requirem.ents .  Two  types  of 
these  specifications  will  be  prepared. 

(1)  Type  C2  -  Critical  Item  Product  Specification.  These 
specifications  will  be  prepared  for  engineering  or  logistic  critical  I-S/A 
AMPE  items.  They  may  be  prepared  as  function  or  fabrication  specifications 
(See  Appendices  IX  and  X  of  MIL-STD-490). 
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i2)  Type  C5 
of  yiL-STD-490). 
prootction  of  tne 
are  asea,  B  types 


-  CoiiipLiter  Program  Proauct  Specif ication  (see  Appendix  XII 
Tin's  type  of  specification  will  be  prepareo  for  the 
I -S/A  .-^MPE  computer  programs,  .vnen  t-.o-part  speci  r  i cat  ions 
snail  form  Part  I  ana  C  tyoes  shall  form  Part  II. 


1.1  Interrace  Control  Bocument 


Tnis  Qocument  is  complemeiited  by  the  Interface  Control  Document  (ICD), 
'.■.nicn  serves  as  the  repository  for  eiivironmerital ,  raecnanical ,  electrical, 
protocols,  format,  ana  human  interface  criteria  controlling  or  constraining 
tne  development  of  the  I -S/A  hMPE. 


1 .2  Standard  Definitions  ana  Terminology 


To  insure  consistent,  accurate  and  concise  application  of  terminology, 
this  document  contains  a  glossary  of  terms  and  acronyms  (Section  10.0). 
References  may  be  made  to  the  applicable  documents  in  Section  2.0  for 
information  to  supplement  that  contained  in  Section  10.0. 

1 . 3  Pre-Planned  Product  Improvement 

Tne  I-S/A  AMPE  is  being  implemented  in  two  parallel  and  interlocking 
tracKS.  Track  I  involves  the  development  of  a  system  incorporating  those 
required  functions  which  can  be  implemented  using  current  state-of-the-art 
practices.  Track  II  will  implement  the  I-S/A  AMPE  interface  to  the  Defense 
Data  Network  ana  provide  full  consolidation  of  DSSCS  and  GENSER  facilities. 
Sub-section  3.12  provides  a  more  detailed  discussion  of  the  intended 
Pre-planned  Product  Improvements  (P^I). 

1 .4  Change  Procedure 

All  changes  to  this  document  will  be  processed  in  accordance  with 
Appendix  II  of  the  Management  Engineering  Plan,  I-S/A  AMPE  Functional 
Requirements  Change  Process.  All  Services  and  Agencies  that  utilize  the 
AUTOOIN  will  be  members  of  the  Integrated  AUTODIN  System  Requirements  Panel 
(lASRP).  This  panel  will  have  the  responsibility  for  obtaining  ratification 
of  all  proposed  changes  to  requirements  documents  associated  with  the  I-S/A 
AMPE  program  and  will  operate  according  to  the  provisions  of  the  lASRP  charter. 


SECTION  2 

APPLICABLE  UOCLIMEMS 


2.0  REFEREi'.CED  LOCbXERTS 


2 . 1  r-'iilitsry  ana  Feoeral  Standaros 


FED-STD-1031 

FED-STD- 1037 
FilL-STJ-'ioS- lOu 

MIL-ST0-1S8-114 


Telecormunicaticns ,  General-Purpose  37  Position  and 
9  Position  Interface  Betvveen  Data  Terminal  Equipment 
anc  Data  Circuit  Terminal  Equipment 

Telecommunications  Terms  and  Definition 

Common  Long  Haul  ana  Tactical  Commun ication  System 
Technical  Stanoarcs 

Electrical  Characteristics  of  Digital  Interface 
Circuits 


MlL-STD-lSS-12d 

:'TL-STD-188-310A 


MlL-STD-470 


MlL-STD-483 


MIL-STD-490 

MIL-STD-785A 

MIL-STD-756A 

MIL-STD-731C 

MIL-STD-1472 

MIL -STD- 1521 A 

MIL-STD-1679 

MIL-E-4158E 

MlL-H-232 


Grounuing,  Bonding  ana  Shielding 

Suosystem  Design  ana  Engineering  Stanaards  for 
Technical  Control  Facilities 

Maintainability  Program  Requirements  (for  Systems 
and  Equipments) 

Configuration  Management  Practices  for  Systems, 
Equipment,  Munitions,  and  Computer  Programs 

Specification  Practices 

Reliability  Program  for  Systems  and  Equipment 
Development  ana  Proauction 

Reliability  Prediction 

Reliabil ity  Tests,  Exponential  Distribution 

Human  Engineering  Design  Criteria  for  Military 
Systems,  Equipment  and  Facilities 

Technical  Reviews  and  Audits  for  Systems,  Equipment, 
and  Computer  Programs 

Software  Development 

General  Requirements  for  Ground  Electronic  Equipment 
(C)  RED/BLACK  Engineering-Installation  Guidelines  (U) 


MIL-H-46855B 


Human  Engineering  Requirements  for  Military  Systems, 
Equipment,  and  Facilities 
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J 


J.2  Gcu  Cifcciives,  Instructions,  ana  .'-ianuals 


Liou  52Co.2y 


Managen.ent  of  Cctiputer  Resources  in  Major  Defense 
i^stesns 

Security  Kequiren.ents  for  Automatic  Data  Processing 
(mDP  S:ys terns) 


ADP  Securit7  i-anuai 

Coil  SI.wu.i-R  Informatiuii  Security,  Program  Regulation 

Dou  SuZ0.Z2->.  Inoustrial  Security  Manual  for  Safeguarding 

Classified  Information 

OoD  C-5030.58M  (C)  Defense  Special  Security  Communications  System, 

Security  Criteria  ana  Telecommunications  Guidance 

(U). 

DoD  Manual  7925-1-5  Mutomatic  Data  System  Documentation  Standard 
2.3  uOint/Allied  Communications  Publications 


Dou  5c20.22-M 


OoD  C-5030.58M 


ACP  ICO, 

US  SUPP  1 

ACP  112 

ACP  117, 

Chi\-US  SUP  1 

ACP  117,  US  SUPP-3 


ACP  121,  US  SUPP- 


ACP  122 


ACP  126 


ACP  127,  US  SUPP-1 

and  NATO  SUPP  3 

ACP  131  (  ) 

mCP  167  (  ) 

ACP  198  US  SUPP-1 


CANAP  128( 


(C)  Address  Indicator  Groups  (U) 


(C)  Task/Type  Organizations  (U) 
US  Routing  Indicator  Book 


Defense  Communications  System  Routing  Doctrine 
General  Purpose  Networks 

(C)  Communications  Instructions  -  General  (U) 

(C)  Communications  Instructions  -  Security  (U) 

(C)  Communications  Instructions  -  Teletypewriter 
(Teleprinter)  Procedure  (U) 

(C)  Communications  Instructions  -  Tape  Relay 
Procedures  (U) 

Communications  Instructions  -  Operating  Signals 

Glossary  of  Communications-Electronic  Terms 

Instruction  for  the  Preparation  of  Communications 
Electronics  Publications 

Automatic  Digital  Network  (AUTOOIN)  Operating 
Procedures 
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DUI  101 


(Secret  Coirpartirentea  Ooccnent)  Defeiise  Special 
Security  Coninieni  cat  ions  System  (DSSCSj  Aocress 

dt'cups  ( u/iG )  (u) 


DO  I  102 


OOi  103 


l,Secret  Compartmenteo  Document)  Oetense  Special 
Security  Communications  System  Operating 
Instructions  -  Routing  Inaicatcrs  (U) 

(Ccnf ioential  Ccrpartmentea  Document/  Derense 
Special  Security  Coirmur.  i  cat  ions  System  Operating 
Instructions  System/Data  Procecures  ^U) 


2."  Service/Mqencj  Telecommunications  Instructions  and  Proceoures 


hFM  10-4 


AR  105-32 


CDOU  PLAU 


NTP  3  SUPP-1( 
u'TP  4 

NAVELEX  INST 
5200.23 

DCAC  300-175-9 


DCAC  310-55-1 
DCAC  310-D70-30 


DCAC  310-D70-55 


DCAC  310-130-1 
DCAC  310-0130-3 


DCAC  370-D95-1 


DCAC  370-D175-' 


DCAC  370-0195-1 
DCAC  370-D195-2 


Air  Force  Directory  of  Unclassif ieo/Classif iec 
Aodresses 

Autnorizeo  Actresses  for  Electrically  Transmittea 
Messages 

Joint  Department  of  Defense  Plain  Language  Acoress 
Directory 

)  Plain  Language  Address  Directory 
Mooir ications  to  ACP-126 

Computer  SoTtware  Life  Cycle  Management  Guice 


DCS  Operation-Maintenance  Electrical  Performance 
Stanoaras 

Status  Reporting  for  the  DCS 

DCS  AUTODIN  Switching  Center  and  Trioutar.y  Operation 

(C)  DCS  AUTODIN  Defense  Special  Security 
Communications  System  Routing  Doctrine  (U) 

Submission  of  Telecommunications  Service  Requests 

Approveo  DCS  AUTOOIN  Terminal  Systems 

System  Description  OCS-AUTODIN 

Interface  and  Control  Criteria 

DCS  AUTOOIN  Interface  Category  I  Testing 

DCS  AUTOOIN  TEMPEST  Category  II  Testing 


370-1^  19c-3 


uCS  AJTUuir'i  CdtcjOf'y  III  Upcri^tionil  nCCcpCcncc 
Test 


U.-r-,- 


uol.  i^JEC 

Trusteu  Computer  Systesr  Evu,..ati:t:  Criteria, 

'.aj  l^jo.:  Draft) 

uSSID  307 

(Secret  Compartmentec  Docunient)  SIGINT  Product 
Uistrioution  (j; 

cSSID  3C9 

(Secret  Ccmpartn’entec  Docunienc)  .'■^anuai  of 
n;.tnoriccu  SIGII.T  Procuct  Kecipients  JJ) 

uSSlO  505 

(Secret  Compartmentea  Document)  Directory  of  SIGINT 
Orgainzations  (U) 

USSID  519 

(Top  Secret  Compartmentec  Document)  Delivery 
uistrioution  Indicators  (U) 

JIA  Publication 

^Secret  Com.partmented  Document)  Comoartmented 
Mccress  Book  iU) 

2.5  Otiier  References 


a.  Draft  AuTODIiN  I  System  Functional  Specification,  DCA  B652,  Mugust  1982 

b.  I-S/A  A^'PE  Functional  Statement  Document  (Section  I,  II  and  III),  DCA  23 
SEP  82 

c.  Jensen,  Randall  'a.  ana  Tonies,  Charles  C.,  "Software  Engineering", 
Prentice  Hall  1979. 

d.  HAVEuEX  Software  Management  Guioebook  Vol.  I  "Software  Acquisition 
Monitoring. " 

e.  Defense  Data  Network  Program  Plan,  DCA,  January  1982  with  changes. 

f.  Nibalai,  6.H.,  "Proposeo  Technical  Evaluation  Criteria  for  Trustee 
Computer  Systems,"  M79-225,  The  MITRE  Corporation,  Bedford,  MA,  25 
October  1979 

g.  E.  T.  Trotter  &  P.  S.  Tasker,  "Inoustry  Trusted  Computer  System 
Evaluation  Process,"  The  MITRE  Corporation,  Beaforo,  MA,  1  May  1980 

h.  Nibaldi,  G.  H.  "Specification  of  A  Trustee  Computing  Base  (TC8)," 
;'179-228,  The  MITRE  Corporation,  Bedford,  MA,  30  Novemoer  1979 

1.  M.  H.  Cheheyl,  M.  Gasser,  G.  A.  Huff,  J.  K.  Mi  lien  "Secure  System 

Specification  and  Verification:  Survey  of  Methoeo logies , "  MTR-3904,  The 
MITRE  Corporation,  Beefore  MA,  20  February  1980 

j.  Nomenclature  Internationale  des  bureaux  oe  poste  -  Universial  Postal 
Union  -  Bern  Edition  1977  w/changes  Index  Printers,  Dunstable, 
Bedfordshire,  England 

2.6  Selectee  Papers  on  Secure  Systems  Developn:ent 

Tne  following  is  a  partial  list  of  papers  in  the  area  of  secure  systems 
development. 


(A.T.es73)  ,  Anies,  S.  R.,  "Design  of  a  Message  Processing  System  for  a 
Multilevel  Secure  Environment,"  MTR-3449,  The  MITRE  Corporation,  Bedford, 
Massachuse tts,  (June  1973). 

(Ander3on72 ) ,  Anderson,  J.  ?.,  "Computer  Security  Technology  Study," 
ESD-TR-7  3-51 ,  Volumes  I  and  II,  Ja.mes  ?.  Anderson  &  Company,  Fort  Washington, 
Pennsylvania,  (October  1972). 

(3ell73),  Bell,  D.  E.  and  LaPadula,  L.  J.,  "Secure  Computer  Systems," 
ESD-TR-73-273 ,  Volumes  I  and  II  and  III,  The  MITRE  Corporation,  Bedford, 
Massachusetts,  (November  1973-June  1974). 

(Biba75),  Biba,  K.  J.,  "Integrity  Considerations  for  Secure  Computer 
Systems,"  MTR-3153 ,  The  MITRE  Corporation,  Bedford,  Massachusetts,  (June  1975) 

(Burke76),  Burke,  E.  L.,  "Secure  Minicomputer  Architecture,"  MT76-224, 

The  .MITRE  Corporation,  Bedford,  Massachusetts,  (October  1979). 

(Cheheyl79)  ,  Cheheyl,  M.  H.,  Huff,  G.  A.,  Gas.'er,  M.,  Millen,  J.  K., 
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2 . 7  Industry  Specifications,  Instructions  and  Manuals 


3 . 0  REijU  lKL:''iEi'iiS 


3 . 1  General  I-S/A  A'-'PE  Objectives  a'".c  Ccncepts 

Tills  GOCLitiient  estaolisnes  tne  runciional  ana  perf ormance  recu i rements  r'or 
tne  Geve lopiiient  or  rne  I-S/n  ^iVE  rur  jSc  o'j  all  Services  ar.c  Agencies.  The 
'iulti-level  secure  I-S/m  mT.PE  is  a  key  element  in  the  Integrated  AUTODIi'; 

System  ana  '.vill  ue  comprised  uT  tnree  runctional  modules;  netv/ork 

communications,  service  processing  anc  user  rera'inal.  T-.e  I-S/A  A.i.rE  .vill  be 
a  nc  sucscriDer  of  the  Oefense  jata  ,'.et.vcr<  (l'DA;  and  as  such  neees  the 
iiost  -nost  protocol  str ^cture  reguit'ed  to  directly  interrace  a  racket 
S/,itcning  hoce  (PSh)  or  tne  DLiIi,  tnus  the  networK  communications  mocule.  Tne 
service  processing  module  proviaes  tlie  Formal  i-iessaqe  Service  (FMS),  hiiile  tne 
user  terminal  module  proviaes  the  requisite  man  machine  interface  (e.g., 
keyboard,  video  display  and  printer).  Current  state-of-the-art  technology 
shall  be  exploited  in  the  construction  of  the  I-S/A  AMPE  equipment.  The  I-S/A 
AT’.PE  shall  fulfill  the  follovving  requirements:  ' 

Provide  a  multi-level  secure  certified  and  accredited,  standard 
automated  telecommunications  m.essage  processing  system  v/itn 
capabilities  based  on  validated  Service/ngency  requirements.  The 
developed  baseline  system  will  provide  the  minimum  essential 
functional  capaoilities  currently  existing  in  DoD  automated 
telecommunications  message  processing  systems. 

.  Provide  a  functional  replacement  for  the  current  AUTODIN'  Switching 
Centers  (ASCs)  retaining  only  the  functions  required  to  support 
AUTODIN  users. 

.  Provide  an  interface  to  the  Defense  Data  Network  (DDN). 

3.1.1  The  I-S/A  Af^PE  as  an  Element  of  the  Integrated  AUTODIN  System 
Architecture 


The  major  objective  of  the  Integrated  AUTODIN  System  (IAS)  is  to  provide 
system  commonality  and  compatabi lity  in  record  and  data  processing  within  the 
Defense  Communications  System  (DCS).  The  IAS  Architecture  (lASA)  is  the  plan 
defining  the  types  of  systems  (in  terms  of  processing  and  interface 
capabilities)  required  to  support  the  IAS  objectives,  while  enhancing  the 
capabilities  of  the  current  DCS  structure.  As  a  key  element  in  the  lASA,  the 
I-S/A  AMPE  will  be  the  standard  system  which  will  replace  the  automated 
message  processing  exchange  of  all  DoD  Services  and  Agencies.  In  this  regard, 
the  prime  objectives  in  the  development  and  implementation  of  the  I-S/A  AMPE 
are  as  follows: 

To  standardize  the  telecornmunications  services  performed. 

To  identify  and  standardize  interface  capabilities. 

To  decrease  overall  operating  ana  maintenance  costs. 

To  eliminate  duplicate  efforts  in  the  development  and  maintenance  of 

message  processing  systems  and  subscriber  terminals. 


Tne  evciution  or  ^he  ImSm  is  cnviaed  into  three  tune  rra.nes  keyed  to  tlie 
aepicyrent  of  I-S/A  A.'-iFE  anc  tne  pnase  cut  of  mSCs.  The  hear-Ten:;  is  oerinta 
as  that  ti,:c  prior  to  fieicirg  of  tne  I-S/A  jhe  Mid-Term  begins  v.'itii 

tne  fialdi'''  0‘‘  tne  l-Z.'n  ~  PE  ano  conoluces  .'litii  the  phasing  out  tne  last 
^SC.  Tile  Far-Term  is  ucfir.eo  as  me  time  fraiie  followinq  piiase  out  or  all 


3.1.2  Tne  hear-^e*''"  IAS  Architecture 

Tne  maj^r  ,'.ear-Ter'i’  activity  ivill  oe  the  implementation  of  t;  a  Eef-nse 
.^■atd  iicZ.iCi'\  ific  Li^ii  is  a  secured  paciset  sv.i  tching  netv/or^  PesicneG  t 

provide  a  packet  transport  oacKpone  capability  for  the  IAS. 

In  the  i\ear-Term,  as  depicted  in  Figure  1,  the  PSNs  will  support  only  the 
DON  subscribers  and  will  not  interface  with  tne  AUTODIN  community.  During 
this  time  frame,  AUTODIN  should  not  experience  major  changes  or  enhancements 
except  for  urgent  mission  requirements  ano  those  necessary  to  miaintain  ASC 
viacility  througn  tne  IAS  mid-term.  The  following  Automated  Message 
Processing  Exchanges  (AMPEs)  will  be  operational  in  the  near-term  IAS:  Army' 
A.'riE,  Navy's  LDMX,  ^lir  Force's  AFAFiPE,  NSm's  STREAMLINER,  ano  DLA's  AMPE.  In 
tne  near-term,  the  interface  for  the  TRI-TAC  AN7TYC-39  switches  and  the  NICS 
■^ARE  switcnes  to  AUTODIN  will  be  via  the  ASCs.  In  this  period,  the  I-S/A  AMP 
will  te  developed,  implemented  ano  prototype  tested. 


3.1.3 


iio-Term  lAS  Architecture 


with  the  advent  of  I-S/A  AMPE  Initial  Operational  Capability  (IOC)  the 
Mid-Term  US  oegins  ana  it  lasts  until  the  Goal  USA  has  been  achieved  (the 
last  of  the  ASCs  has  been  phased  out).  Each  I-S/A  AMPE  will  initially  serve 
either  the  DSSCS  or  the  DENSER  comimunity.  The  DSSCS  I-S/A  AMPE  will  be 
accessed  only  by  Top  Secret  and  Special  Compartmented  Intelligence  (SCI) 
cleared  personnel  and  traffic  between  them  will  be  End-to-End  Encryption 
(E^)  protected.  As  trusted  computer  base  technology  matures,  segregation  of 
DSSCS  and  GENSER  facilities  will  be  eliminated.  During  the  Mid-term  IAS, 
initial  deployment  of  the  I-S/A  AMPEs  will  be  undertaken  and  the  I-S/A  AMPEs 
will  be  required  to  assume  the  terminal  support  functions  of  the  ASCs.  The 
I-S/A  AMPEs  will  be  the  element  that  will  ultimately  allow  members  of  the 
Formal  Message  Service  (FMS)  community  to  exchange  message  traffic  with 
members  of  the  Virtual  Connection  Service  (VCS)  community.  These  changes  are 
illustrated  in  Figure  2.  Once  the  Goal  Architecture  is  fully  achieved,  the 
US/A  AMPEs  and  PSNs  will  fully  replace  the  ASCs.  Further  the  I-S/A  AMPE,  in 
its  role  as  an  ASC  functional  replacement,  will  provide  the  interfaces  to 
TRI-TAC,  other  non-DoO  U.S.  networks  (State's  Diplomatic  Telecommunications 
Service  (DTS)  and  GSA's  Advanced  Record  System  (ARS)),  specified  allied 
networks,  and  the  NATO  alliance  NICS  TARE  switches  as  do  ASCs. 

3.1.4  The  Goal  and  Far-Term  IAS  Architecture 


The  Goal  Arcnitecture  is  illustrated  in  Figure  3.  During  the  Transition 
Phase,  the  I-S/A  AMPEs  will  be  replacing  existing  AMPEs.  Certain  of  these 
AMPEs  will  have  economic  service 
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lifetiii;es  .vnicn  wil]  extenc  ceyon'j  ttie  Mia-term  ana  are,  therefore,  inclocea 
in  tne  Goal  Arcni tecture.  Tne  I-o/A  m-'.PE,  in  its  role  as  che  integrator  of 
FMS  and  VCS,  .-jill  -.Itimately  provide  network  value-anoed  services  to  selected 

sooscriOers  in  accition  to  c...rrent  AoTODIh  F.'-iS  terminals.  For  exanole, 
tne  I-S/,-  n.vPt  provioes  an  FMS  similar  to  tne  current  AUToDi'.  narrative/tata 
n;essage  service  to  directly  cannecteo  subscrioer  ana  ultimately  to  selected 
remote  suoscriber  v.no  access  tiie  I-S/A  hI-'.PE  tnrougn  the  network.  Furti-ier 
details  on  tne  interface,  netwar\  service  and  data  'lov.'s  to  te  prcviJc-c  oy  the 
I-d/.-A  -i'Pi  are  ccntuineo  in  para'^-'upn  3.1.5  ana  its  Subparacr  sons . 

I'le  tar-.crit  j.rS  l-CrsS  to  a  complete  'iritegration  ot  narrative,  recorc  ai’c 
Gdta  com.ihunications  services  worlawice.  There  is  expecteo  to  oe  a  continuing 
evolution  of  tne  Integrated  AUTODIN  System  as  the  CCS  continues  to  mature 
toward  a  w'orlo  Wioe  Digital  System  Architecture  (wwDSA).  New  IhS  services  are 
expected  to  be  developed  in  response  to  user  requirements.  The  initial  I-S/A 
AiMPE,  as  an  IAS  network  element,  may  be  requireo  to  provide  some  of  the  new 
AUTOCIN  services  sucn  as  improved  message  profiling  and  retrieval,  message 
processing  wcrxlcad  snaring,  teleconferencing  and  mail  box  service.  Tne 
design  or  tne  IOC  I-S/A  AMPE  shall  allow  for  expansion  of  services  such  that 
the  incremental  addition  of  new  features  witnin  the  basic  loC  I-S/A  AMPE  can 
ce  accomplisnea  with  minimal  impact  on  the  existing  software  after  taking  into 
account  security  constraints.  Paragraph  3. 1.5.4,  I-S/A  mMPE  Design 
Requirements,  discusses  tnis  requirement  in  more  oetail.  This  document 
specifies  the  requirenients  for  the  I-S/A  AMPE  for  the  Goal  lASA  (See  Figure  3). 

3.1.5  I-S/A  AMPE  Concept  of  Operations 

The  I-S/m  AMPE  is  tne  element  of  the  IAS  Goal  Architecture  providing 
Formal  Message  Service  (FMS)  incluoing  a  Message  Eoiting  and  Preparation 
Service  (MEPS),  and  network  access  to  botn  the  FMS  and  VCS  community  of 
terminals  (See  Figure  4).  In  this  role,  the  I-S/A  AMPE  views  all  other  I-S/A 
AMPEs  as  directly  connected.  For  example,  in  Figure  4  I-S/A  AMPE  ?1  views 
terminals  A  ana  d  as  oirectly  connected  to  itself  ana  terminals  C  and  D 
directly  connected  to  I-S/A  AMPE  z2.  I-S/A  AMPEs  also  view  other  I-S/A  AMPEs 
as  directly  connected.  In  Figure  4  I-S/A  AMPE  =1  ana  view  each  ctner  as 
cirectly  ccnnectec. 

There  are  two  types  of  paths  to  users  that  are  unoerstood  by  the  I-S/A 
AMPE.  These  are;  1)  paths  to  users  physically  connected  to  the  I-S/A  AMPE 
(in  Figure  4  I-S/A  AMPE  -^1  views  terminals  A  and  B  in  this  manner)  and  2) 
virtual  paths  which  connect  users  (or  other  I-S/A  AMPEs)  to  the  I-S/A  AMPE  via 
the  backbone  network.  For  example,  based  on  Figure  4,  I-S/A  AMPE  #2  can 
establish  virtual  paths  through  the  DON  oackbone  to  Terminal  C,  I-S/A  AMFE  =fl, 
and  the  Host. 

The  Goal  IAS  Architecture  provices  two  distinct  and  separate  addressing 
schemes,  the  AUTODIN  Routing  Inoicator  (RI)  addressing  and  the  DDN  logical 
addressing.  The  I-S/A  AMPE  shall  be  capable  of  translating  from  one 
aodressing  scheme  to  the  other.  Specifically,  the  I-S/A  AMPE  shall  be  capable 
of  maintaining  both  the  AUTODIN  and  DDN  addresses  for  all  appropriate  IAS 
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SuOscriDcrs ,  aiic  it  snail  bt  capaole  of  using  that  infcnration  lo  effect  tne 
■jelivery  of  traffic  to  any  afrccteu  IAS  suDscrioer. 

w .  1 .  j .  1  I  “ S/ A  nt'.r  1  Ser'y  i  c as 

~oe  cefinition  cf  the  IAS  has  lea  to  tne  iOcntif ication  of  several  network 
services  oesigned  to  meet  both  existing  ano  anticipated  DoD  user 
req^i''e!!ie!its .  Tile  service  ot-ovi^ea  curing  tne  ‘■iia-Ierin  by  tne  IOC  I-S/A  A-'-'PE 
snail  be  rorral  .’ess ace  Service  ^F,'-S;  .,itn  its  /:essage  E^itin.g  ^nc  Pr-p^raticn 
-■rr/iae  -EPS).  Accitional  services  suen  's  impreveo  iressage  :rQfilir.c  aov. 
r-f'-ieval,  .r.essace  prcc^ssir.g  ..cr<lcaa  snaring,  teleccrirerenci.  g,  anc  sail  box 
service  are  intencec  to  oe  proviaea  in  tne  Far-Tenn.  Tne  arcnitecture  of  tne 
I-S/A  AFiPE  (hardware  anc  software)  will  oe  sufficiently  flexioie  to  allow  the 
introduction  of  new  functions  as  they  become  valioated  ano  available,  ana  the 
mocification  of  existing  functions  as  necessary  throughout  tlie  service  life  of 
the  system. 

S.l.b.l.l  Formal  ^^^',essaGe  Service  (FMS) 


FMS  provides  tne  capability  for  suoscrioers  to  create,  sene,  and  receive 
for.mal  messages.  FMS  can  be  regarceo  to  oe  a  continuation  of  the  current  AIIPE 
functions  ano  the  AUTODIh  message  sevice.  Formal  messages  are  oefined  as 
messages  based  on  the  16  line  military  inessage  format  that  are  prepared, 
releasea,  hanaled,  ano  recorcea  for  storage  in  accorcance  witii  Service/egency 
procecures.  The  I-S/A  AMPE  FMS  shall  support  both  DSSCS  ana  6£i\'SER  traffic  in 
all  but  not  limited  to,  the  following  formats:  JAi\AP  128  (narrative  ana 
data),  001-103,  ACP  127,  and  ACP  126  (mocified)  formats,  as  well  as  Joint 
ivessage  Form  (DO  Form  173)  input.  The  FMS  will  perform  those  message 
processing  ana  routing  functions  necessary  to  replace  AWPE  ano  ASC  message 
functions.  Detailed  requirements  for  FMS  are  specified  in  3.2.1. 

3.1.5. 1.2  Message  Eoiting  ana  Preparation  Service  pMEPSj 

The  I-S/A  AMPE  will  provide  the  capability  to  guide  the  message  preparer 
through  the  process  of  entering  a  message.  This  function  includes  automatic 
supervision  of  message  preparation,  including  message  mask  call-up  ana  message 
editing  capabilities.  Messages  entering  the  I-S/A  AMPE  via  an  Optical 
Character  Reaaer  (OCR)  will  conform  to  the  standard  DO  173  format  (ACP-121 
US-SUPP-1).  An  editing  capability  will  permit  the  message  preparer  to  make 
corrections  and  changes  to  a  message  both  during  and  after  entry  but  prior  to 
release.  Editing  will  permit  additions,  aeletions,  and  replacement  or 
characters,  woras,  and  lines.  Detailed  requirements  for  MEPS  are  specified  in 
3.2.2.  MEPS  will  validate  the  applicable  portions  of  the  DO  173  entries  ana 
if  correct  will  perform  format  conversion  to  either  JAi\AP  123  or  DOI  103. 

3. 1.5. 1.3  Future  IAS  Services 

The  IOC  I-S/A  AMPE  is  to  be  designed  and  implemented  so  new  functions  & 
capabilities  can  be  incrementally  aaaea  within  tne  basic  IOC  I-S/A  AMPE 
without  requiring  major  modifications  to  the  existing  hardware  or  software. 
Improved  Message  Profiling  and  Retrieval,  Message  Processing  WorKload 
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Sftariiic,  Itircrr'.al  .‘•essa^e  Service  [I'-'iS),  Teleconferencing  Service  (TCS)  ana 
c,aia  :ise  ■'ransaction  Service  iSET;  are  canaiaate  services  wnicn  mignt  be 
accec  :o  are  I-S  -*  nl-'PS  in  ane  fui'-re.  uce  section  5.12  iur  P^I). 

• .  I . : . ' .  -  .irac.al  r^riecai..n  jerviae  y.t  S  _ 

■.CS  proviaes  the  basic  transport  capaoility  of  tne  DD'.  to  the  I-S/A  A, -'.PE 
via  tfic  protocol  strjctur=  set  of  protocols  froni  TCP  tnrougn  ano 

irclucin-  tne  eu.',  interface),  ^-.t  I  C  tne  '.CS  shall  proviae  t  ie  reliable 
''\r, a  -T  pac<ets  rrc  i.  I-S,'m  F'-.S  ao  l-S/A  /^MPE  ET.S  anc  rrofii  terrirals 

Ownrecteo  tu  otr.er  I-iS  elerenas  ^e.g.,  ’■.ol  ti  level  secure  Tcr.v.^'al  Access 
Controller)  to  ane  FT'S  or  an  I-S/A  nAPE.  vCS  is  to  be  .iSeo  Dj-  all  otner 
services  in  the  ImS  to  obtain  DDt,  long  haul  trunking. 

3. 1.5.2  I-S/A  AMPE  Interfaces 

Tne  IOC  I-S/A  A', PE  is  to  implerent  a  stancard  set  of  interfaces  and 
protocols  to  cor.rrunicdte  .\itn  standard  subscrioer  terminals  anc  tne  InS 
net’.vor<.  In  order  to  meet  specific  subscrioer  reqj irements ,  variations  to 
t.nese  stancaro  interfaces  .-.ill  also  ce  accoramocateo .  The  details  of  these 
interfaces  are  specified  in  tne  Interface  Control  Cccument  (ICD),  paragrapns 
A, 2.2  ano  5.1.2.  Aaoiticnal  intertaces  may  ce  adoed  post-IOC  as  neiv 
requirements  are  valiaateo. 

3. 1.5. 3  I-S/A  r.APE  Data  Patti  Control 

The  I-S/A  AAPE  provides  services  to  its  subscribers  via  the  establishment 
of  data  flow  paths.  Tne  I-S/A  AAPE  estaolisnes  data  flow  paths  between 
subscribers,  between  subscribers  anc  services,  ano  between  services.  The 
service  management  function  of  the  1-S/m  AMPE,  see  paragraph  3.2.3,  cohtrols 
the  estao 1 ishmeht,  use  ahd  termination  of  these  data  flow  paths.  The  data 
flow  paths  the  I-S/A  AMPE  shall  support  are  described  below.  Tne  following 
definitions  apply: 

User:  An  I-S/A  AMPE  user  is  any  organization  or  activity  that  obtains 
service  from  the  I-S/A  AAPE.  A  user  may  obtain  this  service  by  use  of  its  own 
equipment  connected  to  the  I-S/A  AMPE  or  by  obtaining  "over-the-counter" 
service  from  a  telecommunications  center. 

Subscriber:  An  I-S/A  AMPE  subscriber  is  an  IAS  "user"  that  uses  its  own 
equipment  homed  to  an  IAS  element.  The  term  "subscriber  "  means  either  a 
terminal  with  its  associated  operator  or  a  host.  Subscribers  are  further 
categorized  as  local  subscribers  and  remote  subscribers.  A  local  subscribers 
circuit  terminates  on  the  I-S/A  AMPE.  A  remote  subscriber's  circuit 
terminates  on  another  IAS  element  (e.g.,  TAG),  and  the  remote  subscriber 
accesses  the  I-S/A  AMPE  through  the  networK  to  obtain  service. 

Terminal :  An  IAS  terminal  is  a  piece  of  subscriber  equipment  capable  of 

handling  only  one  logical  channel  at  a  time  to  the  IAS. 

Host:  An  IAS  Host  is  a  piece  of  subscriber  equipment  connected  to  the  ImS 

backbone,  the  OD'J,  and  is  capable  of  simultaneously  processing  multiple 

logical  connections  to  the  IAS. 


Data  Flow  Paths 
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nr. PE,  its  suDScribers,  ana  tne  InS  network.  Tuese  cata  paths  are  aescribeo 
Cclow  ana  specirieo  in  paragrapn  3.E.3.I.  Tne  security  related  attrioutes  are 
prescrioco  in  Section  3.4. 

...a.  .ocai  £  .:.sc''~iaer  t^  .,ccal  Service 

T-ie  local  S',.cscrioer  to  local  service  oata  flo.v  path  allows  sobscribers 
irectly  connected  to  an  I-S/A  AMPE  to  access  the  service  functions  available 
.vitnin  that  I-S/A  AMPE.  For  the  I3C  I-S/A  AMPE  these  services  are  the  Formal 
.'•lessage  Service  (FFiS)  anc  Message  Eaiting  ana  Preparation  Service  (MEPS). 
However,  adoitional  services  will  be  provided  in  tne  Far-Term  (See  FRD 
3.''.5.1).  Thus,  the  oesign  and  implementation  of  the  IOC  I-S/A  AMPE 
scecirically  in  the  service  management  r'unction  area;  shall  permit  data  flow 
patns  tc  aoditional  services. 

3. 1.5. 3.1.3  bocal  Subscriber  to  Local  Suoscriber 

Tne  local  Suoscrioer  to  local  sucscrioer  data  flow  path  allows  a 
suoscrioer  directly  connected  to  an  I-S/A  AMPE  to  access  another  directly 
connected  subscriber.  This  capability  will  oe  offered  post  IOC,  however,  the 
design  ana  impleiT:entdtion  of  the  IOC  I-S/A  AMPE  shall  permit  this  data  flow  to 
oe  implemented  later. 

3. 1.5. 3. 1.3  Local  Subscriber  to  Metwork 

Tne  local  subscriber  to  networK  data  flow  path  allows  a  subscriber 
directly  connected  to  an  I-S/A  AMPE  to  access  the  network  ana  vice-versa.  The 
capability  for  local  Subscriber  to  the  DON  to  be  implemented  later  shall  be 
included  in  the  IOC  design  and  implementation. 

3. 1.5. 3. 1.4  Service  to  Service  via  the  DON 


A  local  service  in  the  I-S/A  AMPE  shall  have  the  ability  to  establish  a 
aata  flow  path  to  a  service  or  process  located  in  a  remote  host(s)  of  the  DON, 
e.g.,  another  I-S/A  AMPE.  Specifically,  the  IOC  I-S/A  AMPE  FMS  will  require  a 
data  flow  path  to  the  FMSs  located  througiiout  the  IAS  network  in  order  to  pass 
message  traffic.  Post  IOC  when  other  services  are  resident  in  the  I-S/A  AMPE 
the  design  and  implementation  shall  ensure  their  ability  to  use  VCS  to  transit 
the  DDm’. 

3. 1.5. 3. 2  Access  Control 

Tne  I-S/A  AMPE  shall  maintain  positive  access  control  on  behalf  of  all 
suDScribers  it  serves.  Access  control  is  accomplished  as  descri'ea  in  the 
following  paragraphs  and  in  Section  3.4. 
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3. 1.5. 3. 3  i^n^sical  Line  Security  Validation 


Trie  I-S,.  A  Ai-'PE  is  to  nicnitor  tne  security  levels  of  the  ti^dffic  on  all 
access  lines.  All  transactions  receiveo  or  trans-iitteo  on  an  access  lire  rrust 
be  valiOitcc  to  assure  tney  ao  not  exceeo  tne  security  level  tne  line. 

3. 1.5. 3. 4  Subscriber  loentif ication  Validation 

Tne  I-S/A  AMPE  is  to  assure  positive  identirication  of  all  subscribers 
(tcr.rinals  ana  hosts/  accessing  the  I-S/A  AMPE.  The  security  level  requestec 
by  a  subscriber  snail  be  validated  against  a  pre-ueterj.iined,  -^axitu-n 
autnorizec  security  li^vel  for  tnat  subscriber  to  tnsure  the  ii/axitsuit  has  not 
been  exceeaea.  Security  requirenients  are  prescribed  in  Section  3.b. 

3. 1.5. 3. 5  Data  Path  Requests 

Each  validated  subscriber  or  service  requesting  data  paths  in  the  I-S/A 
AMPE  snail  require  further  validation  to  access  either  a  supscriber  airectly 
connected  to  the  I-S/A  AMPE,  a  service  provided  by  the  I-S/A  AMPE  (e.g., 

Formal  Message  Service),  or  a  remote  network  element  locateo  elsewhere  in  the 
IAS  network  (e.g.,  a  TAG,  another  I-S/A  AMPE,  or  a  subscriber  Host).  The 
types  of  services  ana  aata  paths  a  subscriber  or  entry  service  is  authorized 
to  request  shall  be  predefined  by  a  table  (classmark)  and  the  I-S/A  AMPE  shall 
verify  that  the  subscriber  request  is  authorizea  prior  to  granting  access. 
Security  requirements  are  prescribed  in  Section  3.4. 

3. 1.5. 3. 5.1  Access  to  a  Local  Subscriber 


Permission  for  a  validated  subscriber  or  service  to  establish  a  data  path 
to  a  local  subscriber  shall  be  grantea  if  the  request  meets  pre-established 
authorization  criteria.  As  a  minimum,  the  subscriber  must  satisfy  criteria 
relating  to  pnysical  line  security  and  subscriber  validation  as  describee  in 
3. 1.5. 3. 3  and  3. 1.5. 3. 4,  respectively.  The  capability  shall  also  be  provided 
to  classmark  subscribers  as  a  means  to  limit  suoscriber-to-subscriber  data 
paths  to  a  closed  user  group  or  groups  within  the  IAS  subscriber  population. 

3. 1.5. 3. 5. 2  Access  to  a  Service 

Permission  for  a  validated  subscriber  or  service  to  access  a  service 
executing  under  control  of  the  I-S/A  AMPE  shall  be  granted  if  the  request 
meets  pre-established  authorization  criteria.  The  capability  shall  be 
provided  to  classmark  services  to  limit  access  to  those  services  to  a  closed 
subscriber  group  or  groups  within  the  IAS  subscriber  population. 

3. 1.5. 3. 5. 3  Access  to  a  Remote  Network  Element 

Permission  for  a  validated  subscriber  or  service  to  request  a  data  path  to 
an  element  located  elsewhere  in  the  IAS  network  shall  be  granted  if  the 
request  meets  pre-established  authorization  criteria.  The  capability  shall  be 
provided  to  classmarx  subscribers  and  services  to  limit  remote  data  paths  to 
those  authorized  for  specific  subscribers  and  services. 
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iiri  tr'i'or  Process ir. -3 


jL:.3:rireu  >'ec.icsts  for  cafe  oains  shall  be  reportec  as  the_<  occur  to 
-  1-c  -1  .-.-pE  ^ceratcr  posii:iL.ii  tor  resclutior  .  ^'tcurit^'  creacres  cr 
a'lc  ctea  :uc--ru^  Preucnes  '^etectec  py  trie  1-t/P  rc.pL  sr'all  tcL-se  i  -r'eciate 
n.terrupticri  or  tei'ir.i nati Qti  or  trarfic  on  me  affecteo  cata  patn.  Trarfic 
rxcnango  cn  or.arTeCtec  cata  pami  snail  continue  uninterruptec . 


runctional  niocuianty 
anc  ucletion  or  i-S/A 


The  I-S/A 
as  cefinea 

^  K  Pir 

nr.rt 


'li  L  ~  ^  -‘/r'd  IS  C’lc  TcD  1  dC  rilicfi  u  fCT  aMu  bcT'V  1  C*f/ dS.  .fit: 

I-S/n  mPFE  .oil  process  n.essagcs  in  me  rorttats  mat  are  currently  in  use  to 
penrit  a  s-tootn  transition  for  suoscriPer  terminals  as  tiiese  terminals  are  cut 
over  from  tne  ASCs  aiio  Service/ Agency  hXPEs  to  the  I-S/A  mMPEs.  Aoditional 
aesign  requirements  are' prescr ioeu  in  Section  3.4  ana  Section  20.0. 

3 .  i .  5 . 5  A^'  PE  Cesigti  Pccui ret-ents 

3  . 1 . 5 . 5 .  1  Iccu lari  t^.  Concept 

nri  important  requirement  in  the  cesian  ana  cevelcpment  approt  n  for  tne 
I-S/A  rtl'PE  IS  me  concept  of  functicnal  mooularity.  Functional  moou lari ty ,  as 
uScG  nere,  means  tne  grouping  or  all  resources,  (.naruware  anc  sortv.are) 
•'equirec  to  perform  a  runction  sucn  tnat  the  resources  may  be  acc'ec,  mooifiea 
or  removea  .vitnout  affecting  other  runctions  or  their  interfaces.  The  I-S/A 
Al'.PE  snail  be  cesignea  ana  implementeo  using  runctional  mocularity  as  cefinea 
above  to  support  the  accition,  troaif ication,  ana  ocletion  of  I-S/A  Af.PE 
interraces,  protocols,  anc  services. 

3. 1.5. 5. 2  Interooerabi 1 i ty  o  Survivability 

Intcroperapi 1 i ty  can  have  a  significant  impact  on  survivability  by 
proviaing  the  necessary  wartime  telecommunication  neeos  even  wnen  a 
significant  number  of  transmission  paths  ana  telecommunications  nodal 
switching  capabilities  are  destroyec.  rnteroperaoi lity  between  tne  UCS  ana 
publicly  availaole  communication  facilities  can  provice  immense  reserve 
capacity  and  high  flexibility  in  times  of  crisis  or  natural  disasters,  and  can 
also  enhance  com,mand  and  control  functions  by  facilitating  message  exchange 
among  organizations  which  currently  cannot  coiT.municate  directly.  In  order  to 
interoperate  witn  DCS  and  publicly  available  communications  equipments  and 
networKS,  the  I-S/A  APiPE  shall  incorporate  all  of  the  protocols  ana  interfaces 
specified  in  the  ICD. 

3. 1 .5.5.3  Security 

Security  is  of  major  importance  in  DCS  networks.  The  I-S/A  AMPE  shall  be 
cesigned  and  implemented  to  meet  the  security  requirements  specified  in  3.4. 

3 . 1 .  5 . 5 . «  AKPE  System  Objecti ves 

Tne  I-S/A  AMPE  will  be  orie  ot  tne  mosc  important  elements  of  the  IAS.  The 
aesign  objectives  of  the  I-S/A  AMPE  include: 
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Serving  as  a  oasis  for  replacing  existing  Ai-iPEs 

Serving  as  a  oasis  for  phasing  ooi:  ASCs 

Inierfacinq  tne  FMS  ana  VCS  CoiT,::,L.n i c f es  (Post-IJC) 

.  Provioing  flexioility  for  growth  (in  function,  in  tlirougiiput  ana  in 
tne  acility  to  terannate  customers)  by  expansion  of  its  systems 
f^ncticns,  features,  and  services. 

In  its  initial  conf i guration  the  I-S/A  AifPE  snail  ccntain  the  follcwing 
network  functions: 

Communications  Interface 

Standaro  Subscriber  Protocols 

ASC  and  DOil  interface  Protocols 

ICO  identified  Unique  Link  Protocols 

.  Communications  Processing 

Internet  Protocol  (I?) 

Transmission  Control  Protocol  (TCP) 

Formal  Message  Protocol  (FHPj 

Message  Processing 

Formal  Message  Service  (FMS) 

Message  Editing  and  Preparation  Service  (MEPS) 

.  Transfer  ana  Control 

Service  Management  Function 

Link  Selection  for  Network  Traffic 

Link  Selection  for  Local  User  Traffic 

Input/Output  Internal  Services 

Traffic  Management 

Intransit  Storage 

Statistical  Data  Collection 

Automatic  Report  Generation 
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^=si;r,  aporjuCr  iccptec  'or  zne  iUL  l-S/n  A^.PE  shell  Dt  Surricienilj 
:  zc  Ster'-il  5t:CL.re  iixrener'Lcl  ii:OaL.lar  ennancement  of  tne  ir^S  tnrouen  tf 
i'.r  L  r  ne.s  Turictloral  i:'!jai.les  aric  ent  t-^ansportac  i  1  i  t  \  of  the 
ir-  s^rt.-.ert  riOG^ies  II  otner  i,:  p  lenertatici.  coiiT  i  curat  i  ons  .  Tiie 
■1;  I-S,  r  r-.>,PE  aesic!  si'. all  te  pruousec  ljv  tnt  contractor  anc  ftiay  oe 
>e-  or  a  ramilj'  cr  ccoputer  processors,  a  multiprocessor,  a  set  of 
jt-ocessors,  ur  sonic  cumLi nation  tnereot .  Tne  main  requirements  are  tne 
.j  z^  I'.cct  security  requirements,  assu’^ance  tnat  tne  5Cftv,arc  car.  oe 
leC  or  tne  ranee  c*  oesians  proDcsec  rvicnout  niocirication,  anc  tnat  ai. 


lor, a:  arc 


na>"-.-.C"e  arc  SuCtort  sort.-.are  ,e.q.,  comciier'S,  Oe  ccircletei..  wperatior.a:  arc 
s  u  T  T  i  c  1  er  1 1  j  supporteC  tc  crovice  ror  tne  iiiitici  Gep  icvr.e.nt  ot  tne  SySte't  arc 
tor  Tutu  re  eApansior, . 

n  complete  analysis  of  tne  erfects  anc  maximuiri  limits  of  expancing  tne 
aesign  (narai-.are  ana  software)  snail  be  provibec.  Eacn  type  of  relevant 
coniponent  must  ce  coverec  incluGinq,  for  example,  miain  memory,  I/O 
ccnt'-ollers,  processor(s)  tano'rtictn,  local  anc  remote  terminal  communication 
Support,  anc  nuiroer  of  terminals  supportec.  Any  limitations  of  tne  soTtx-are 
tu  utilize  tne  riarovvare  i.e.G.,  the  inaoility  of  a  vencor  supoliec  operating 
syslK'V  tc  utilize  all  tne  processor  Tear.ures)  snail  oe  laentifiec,  complete 
ursci^ipticn  cf  tne  requirements  for  implementing  aaditions  to  tne  I-S/A  AMPE 
'.•.itmi,  tne  maxinium  limits  shall  be  provioec  anc  wnen  the  aadition  of  equipaient 
requires  tne  accition  of  otner  support  equipment  le.g.,  wnen  aaaing  anotner 
terninal  interface  requires  tne  aaoition  of  a  terminal  concentrator)  it  shall 
oe  iuentified.  Analyses  aepicting  the  effect  of  expansion  on  performance 
leatures  suen  as  tnrougnput  anc  aelay  shall  be  providec. 
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S;-.  A>;PE  Functicns 


T'le  I-S/A  A, ‘-.PE  shall  prcviAe  standard  services  anc  connection  r„nctijns 
for  SLjscribers  locateo  tru'Ouqnouc  the  Integrated  AloTuti'.  Syst-n;  ilAE;. 

Figure  3  shows  a  block  oi agrar?  w i ch  modules  anc  tneir  interconnections  rcr 
illustrative  purposes.  Figure  5  is  not  binding  on  the  contractor;  iicv.ever, 
the  functional  connection  capabilities  prescribea  nerein  are.  Message  Editing 
and  Preparation  Service  (i-iEPS)  ana  Formal  Message  Service  (F,'-iS)  are  tne 
stanoara  services  provicec  at  Ido  by  all  I-S/A  n.-lPEs.  Tne  conr.ection 
functicns  provide  the  interC'.r.rection  cetween  s  bscricers.  ser.-ices,  a:,-, 
remote  netvvorK  ele. tents  and  are  subject  to  security  cons  icerations  prcscricec 
in  Section  3.4  and  access  validation  as  specified  herein.  These  connection 
functions  incluoe  modules  tnat  implement  the  following  protocols:  DDb 
interface  (network  ano  link  layers),  IP,  TCP,  THP,  and  FMP.  The  control  of 
the  aoove  functions  ano  services  is  provided  by  the  Service  Management 
Function  (See  Figure  5). 

3.4.1  Formal  Message  Service  \FMS)  Functions 

3 . 2 . 1 . 1  Message  Processing  Overview 

Tne  I-S/A  AMPE  shall  operate  ana  process  messages  in  accordance  with  ACP 
l4l.  Communications  Instructions  -  General  and  tne  US  Supp-1  thereto;  L-OI-103, 
DSSCS  Operating  Instructions  -  System./Data  Procedures;  unhAP  128,  AUTOblN 
Operating  Procedures;  ano  ACP  127,  Communications  Instructions  -  Tape  Relay  US 
Supp-1  and  r<AT0  Supp-3.  The  FMS  shall  process  message  formats  as  specif ieo  in 
JAbAP  128,  aC?  127,  Modified  ACP  126  (NTP  4),  DOI  103,  abbreviated  ano 
abbreviated  SI.  The  FMS  snail  support  the  OPINTEL  Fleet  Broadcast  (Post-IOC, 
details  to  be  provided  by  NSA).  The  processing  of  messages  by  FMS  shall  be  as 
specified  herein. 

Once  the  FFiS  accepts  a  message  from  a  subscriber  or  a  network  element  as  a 
valid  message,  delivery  snail  be  guaranteed  to  the  appropriate  subscriber  or 
network  element  based  on  the  information  contained  in  the  message  heading. 

All  USSCS  traffic  that  does  not  undergo  Language  Media  Format  (LMF) 
conversion  shall  be  provided  end-to-end  character  and  bit  count  integrity.  No 
technique  for  transmission,  processing  or  switching  shall  be  employee  that 
violates  this  integrity.  Character  count  integrity  is  required  for  all 
letters,  numbers  and  functions  in  DSSCS  traffic;  bit  count  integrity  is 
required  for  binary  stream  data  traffic. 

3 . 2 . 1 . 1 . 1  Input  Message  Processing  Overview 

Messages  that  are  input  to  the  FMS  are  of  two  categories: 
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Originatinc  traffic  tr ans.iii ttec  to  tne  I-S/A  mXPE  oy  ter'rinals. 

tfurric  transuii  ftec  to  an  I-S/,h  rif.PE  via  tne  Fcrinal  '-'cssage 
P>^OtGCG  1  \r  ■?  ]  . 

Traffic  from  jitter  t.-et-vcr-vS  intertuceo  in  tne  terrnna';  iioce  vc.g.,  tne 
AUTOJI''!,  MCS  Tr.KE  ano  TPI-TnC  Networks)  snail  ct;  categorizea  as  originating 
or  terminal  trarric.  Tne  only  traffic  tn^t  shall  be  ccnsi.jeree  netv.'C*'k 
trarric  is  toc  tr.rric  racei.'ea  from  utner  I-b/n  -.i-PEs  vi^  tne  F.XP. 

'•'1  catcCut'i-S  Of  input  messages  sr. all  oe  suoyecteu  to  vaiioatiun  of  tne 
recoirec  format  ^See  Section  3.2. 1.2).  Tne  neacing  of  all  traffic  snail  also 
oe  cneexeo  to  verity  mat  tiie  message  nas  not  been  transmitted  previously  and 
looped  DgCK. 

3.2. 1.1.2  Control  and  Routing  Overview 

Tnrougneut  the  message  processing  cycle,  messages  snail  oe  processed  by 
precedence  and  on  a  f irst-in-f irst-out  (FIFO)  oasis  witnin  precedence  except 
as  specified  in  3. 2. 1.5.1. 

All  messages  shall  oe  subject  to  routing  determination.  There  are  two 
levels  Of  message  routing  witnin  tne  I-S/A  mFiPE.  A  determination  is  made  as 
to  wnetner  the  addressees  are  serveo  oy  the  I-S/A  AF.PE  or  not.  Messages 
destined  for  acoressees  served  by  tne  I-S/A  AKPE  are  categorized  as 
terminating  traffic  ana  are  subject  to  further  delivery  (output  to  subscriber 
terminal)  anu  districution  (messages  annotated  with  distribution  list  for 
manual  distriution  to  users)  processing.  Messages  for  addressees  not  served 
oy  the  source  I-S/A  AMPE  shall  be  categorized  as  messages  tnat  need  to  be 
output  to  the  IAS  network.  These  network  outgoing  messages  shall  be  routed  to 
the  appropriate  I-S/m  AMPE(s). 

The  I-S/A  AMPE  operator  shall  be  provided  tne  status  of  traffic  flowing 
through  the  I-S/A  AMPE.  The  operator  shall  have  the  capability  to  control  the 
flow  of  traffic  via  intercept  ano  alternate  routing  methods  (See  Sections  3.3 
ana  3.2. 1 .5) . 

3.2. 1.1.3  Output  Message  Processing  Overview 

Output  messages  consist  of  terminating  traffic  and  network  outgoing 
traffic.  Terminating  traffic  shall  be  subject  to  distribution  and  delivery 
processing.  The  distribution  (see  Section  3. 2. 1.4. 2.1)  and  delivery  (see 
Section  3. 2. 1.4. 2. 2)  process  shall  determine  whether  any  users  served  by  the 
I-S/A  mMPE  should  receive  the  message  in  addition  to  the  formal  addressees  of 
the  message.  The  distribution  ana  number  or  copies  for  each  serveo  addressee 
shall  also  De  determined.  Format  and  coae  conversion  snail  be  provided  for 
terminating  traffic  as  required  (See  ICO  4.4).  Network  outgoing  messages 
shall  be  routed  to  the  appropriate  I-S/A  AMPE. 

3 . 2 . 1 . 2  Input  Mess  ace  Processing 

Each  message  received  by  the  FMS  shall  be  subject  to  a  set  of  input 
processing  functions  comprising  message  and  format  identification,  subscriber 
verification,  message  validation,  and  security  validation,  as  well  as  any 
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associdtea  error  processing.  Speciric  actions  of  tne  F,”S  regarairg  input 
processing  o:  r.essages  shail  cepenu  un  a  coirbination  of  facturs  incluoing,  out 
r*ot  iinnCcQ  toi 

■’'essa^e  ror:r,ai 

Inout  line  or  circuit 

f'-aroctcristics  or  tr ans;; '  oo i ng  ter.oinal 

u^'iiPiunity  or  interest  or  tne  receiveo  iressage  li.e.,  GEi.SES/  DSSCS) 

.  Severity  of  cetectea  errors. 

The  reniainaer  or  this  overview  describes  the  broad  requirements  and 
purpose  of  message  and  format  ioentification,  message  validation,  and  security 
valication  orocessing  of  iressages  input  to  the  FMS.  Subsequent  sections 
oescribe  tnosc  aspects  of  input  message  processing  common  to  all  input 
traffic,  tnose  aspects  of  input  message  processing  unique  to  terminal  trafric, 
and  those  aspects  of  input  message  processing  unique  to  netv;ork  traffic. 

3.2. 1.2.1  Input  <\essage  Processing  (General^ 

Aspects  of  input  message  processing  common  to  botn  terminal  and  network 
traffic  are  uiscussea  below. 

3. 2. 1.2. 1.1  Xessace  and  Format  Icentif ication 

The  FMS  snail  analyze  all  incoming  traffic  to  identify  the  boundaries  of 
all  receiveo  messages.  Tnis  shall  include  identification  of  message 
delimiters,  for  example,  start-of-message  (SOM)  and  eno-of-message  (EOM) 
sequence.  The  FMS  snail  also  ioentify  and  analyze,  for  each  message,  any 
format  lines  required  to  properly  identify  the  message  format  or  community  of 
interest . 

3.2. 1 .2. 1 . 1 . 1  Acceptable  Formats 

The  I-S/A  AMPE  shall  be  capable  of  identifying  and  accepting  for 
processing  a  variety  of  message  types,  each  with  its  own  characteristics. 

Tnese  shall  incluoe: 

.  uANAP  128 
ACP  127 

.  Modified  ACP  126  (wTP  4) 

DO  Form  173 
DOI-103  CRITIC 

Terminal  traffic  may  be  receiveo  in  any  of  the  above  formats,  while 
networx  traffic  will  be  constrained  to  a  subset  of  the  listed  formats  (e.g.  - 
ACP- 126,  Apbreviated  SI,  etc.  are  processed  into  network  formats  such  as  JAiNAP 
128  and  001-103  prior  to  delivery  or  transmission  to  the  network). 


001-103 

001-103  Special 
Abbreviated  SI 
Abbreviated 
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yessaGe  fcrT.ats  are  cescrioea  in  terms  cf  Fotnr.at  Lines  (FL),  whicii  are 
nuirtereG.  Tne  FL  numbers  usee  nerein  are  tnese  usej  ror  eescrioing  JAivA?  12£, 
aC?  iL7,  ana  all  DUI  iu3  rorracs.  Jei^ai  is  uT  ail  tne  aDcve  Torii'acs  are 
cescriaea  in  tneir  respeccive  ccnaroiling  occiii’;envs  ^-^e  iCD  A. 3). 

3 . 2 .  1 . a .  1 . 1 . 2  ‘-.essaGe  Intecritv 

Tne  I-S/A  AVPE  snail  perrorir,  cnecKS  to  ensure  that  messages  being  received 
a*  ^  tr  ai  s^ui  tiev.  are  complete  enticies  capaGle  or  ceing  processed  anu  tnat  nu 
■".cS sages  .-."e  I'st. 

Tne  I-S/rt  r.'.PE  snail  perferm  straggler  ano  interlace  checking  on  all 
incoining  suoscrioer  messages.  Any  message  tailing  the  straggler  ano  interlace 
cnecK  snail  oe  rejectea  ano  the  subscriber  shall  be  notified.  A  straggler 
message  is  one  rtnicn  either  trails  or  is  attached  to  a  preceoing  message.  An 
interlacea  message  is  one  in  whicn  tne  content  of  two  or  more  messages  have 
been  intermi I-S/n  rtMPE  straggler  processing  snail  cenform  to  oAiiAP  128, 
paragrapns  31g  ^  ic  315;  uOI-103,  paragraphs  520  and  534;  and  000  C-5030-5S-yi, 
Chaoter  3,  paraorapn 

Tne  I-S/o  AF.PE  shall  also  perform  SOM-SOM  (without  intervening  EOW); 
EOy-EOM  (witnout  intervening  SOM),  ana  Channel  Designator  (CD)  and  Sequence 
Muucer  (S.'O  (wnere  appropriate)  continuity  cnecks.  These  cnecks  are  intenoec 
to  Getect  conoitions  where  one  or  more  messages  or  portions  thereof  either 
nave  been  lost  or  may  have  been  lost  (See  uOD  C-5030-58-M,  Chapter  4, 
paragraph  S) . 

Further  the  I-S/A  AMPE  snail  protect  against  the  interleaving  of  portions 
or  two  or  more  messages  in  the  process  of  outputting  messages.  Related 
security  requirements  are  further  describee  in  Section  3.4. 

3. L. 1.2. 1.2  i'.essage  Validation 

The  I-S/A  AMPE  shall  perform  message  format  validation  in  accordance  with 
Section  20.0,  I-S/A  AMPE  Message  Format  Validation,  of  this  document  and  as 
specified  herein.  Taoles  3.2. 1 .2. 1 .2-1  and  -2  specifically  identify  the 
procedures  and  format  rules  by  reference  document  ano  paragraph  in  use  by 
subscribers  entering  messages  into  AUTODIN.  The  I-S/A  AMPE  shall  valioate 
each  message  to  assure  that  the  heading,  text,  and  ending  are  in  accordance 
with  the  specified  referenced  paragraphs  of  Tables  3.2. 1 .2. 1 .2-1  and  -2.  In 
interpreting  the  reference  paragraphs,  the  I-S/A  AMPE  shall  take  on  the 
mission  and  functions  of  the  type  items  it  replaces.  That  is,  any  action 
required  by  an  ASC,  a  Service/Agency  AMPE  or  an  Automatic  Relay  shall  be 
accomplished  by  the  I-S/A  AMPE.  For  example:  Table  3.2. 1 .2. 1 .2-1  JANAP 
128/DOI  103  Message  Processing  Requirements,  Format  Line  15,  EOM  Valioation 
Number  refers  to  Paragraph  315,  316,  and  404  of  JANAP-128  for  narrative 
messages.  Paragraph  315  addresses  Straggler  Messages  and  Suoparagraph  e 
therein  states;  "ASCs  detecting  a  suspected  straggler  message  will  notify  the 
input  station  by  service  message...";  therefore,  the  I-S/A  AMPE  shall,  upon 
detecting  a  suspected  straggler  message,  notify  the  input  station  by  service 
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n.essace....  Tne  I-S/A  Ai'-iPE  siiaii  process  CRITIC  messages  anc  valiaaie  tnac 
cney  are  in  accurdance  '.vicn  paragraphs  201-10^  or  uOI-iw3.  Rerercnce  2. 5. a, 
paragrapns  302  inroucn  3i-.c  and  3!0,  descrioe  no,-,  inpot  n-.essage  orucessing 
>'ea'jirei:.c;!US  are  i-rpleir-ncec  in  ASCs  anc  may  be  uscc  as  a  ,^ice. 


3.2.1.2.i.j  Security  Vai  ioanon 

Tne  1-2  T  a:>PE  s.-ial!  valicate  me  security  class  if  icati  :n  anc  soecial 

V  GT  a.  1  i  cliSaGdS  1'  -  illail  dSSuf''r  ic:'_.^riLy  ^7 

;ac:i  mcssate  :-''Cu:iCut  ai!  phuScs  or  rassa;e  processing.  ..^SCS  messages 
Siiai  I  ue  Su.^^cctcu  to  tne  security  valicaciuii  pr'cccuunes  speciriec  in  ucu 
."dnual  C-5030-dS.;'I,  Cnapter  3,  paragraph  Sno;.  Tne  message  security  snail  oe 
comparec  against  tne  security  level  or  the  particular  connection.  Security 
error  processing  snail  oe  initiatea  whenever  a  message  security  classification 
ana/or  special  handing  aesignators  (SHD)  ana/or  transmission  control  codes 
pCC)  exceed  that  of  tne  connection.  Further  security  requirements  are 
contair.ed  ii.  ucCtion  3. A.  and  Section  .,0.0. 

5. 2. 1.2. 1.4  Error  Processing 

FMS  reaction  to  errors  detected  during  message  and  format  identification, 
message  validation,  or  security  validation  of  input  messages  will  cepeno  on 
tne  severity  of  the  error.  In  genera'',  errorea  messages  shall  be  rejected  by 
the  I-S/A  mi'-IPE  and  appropriate  system  generated  notifications  snail  be 
communicated  to  I-S/A  AMPE  operating  personnel  ana  to  the  message  originator. 
The  errors  for  which  a  system  generated  message  shall  be  produced  are 
specified  in  3.2. 1.5.8. 1.  Further  details  or  error  processing  procedures  are 
listed  in  Section  20.0. 

3.2. 1.2.2  Input  Message  Pi^ocessing  (Terminal; 


The  FFiS  shall  be  capable  of  accepting  formal  message  traffic  from 
peripheral  terminal  devices,  directly  connected  terminals,  ana,  as  a  possible 
p3l  init  iative,  remote  terminals  selectively  "homed"  to  the  FMS  through  the 
DON-  The  I-S/A  ANiPE  shall  also  accept  messages  from  ana  transmit  messages  to 
the  ASCs,  TRI-TAC,  NATO  and  Allied  Countries  in  a  terminal  mode.  That  is,  the 
I-S/A  aMPE  shall  treat  these  network  interfaces  as  terminals  whether  they  are 
in  fact  an  automated  processor  of  a  network  or  a  simple  terminal.  The 
remainder  of  this  section  describes  those  aspects  of  input  message  processing 
unique  to  input  traffic  from  terminals. 
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On  high  precedence  messages  (flash  and  above),  messages  shall  not  bo  rejected  if 
only  this  field  is  invalid;  messages  shall  be  forwarded  to  addressee  and  originator 
stiall  be  serviced  advising  of  invalid  field  and  that  iiKjssage  was  forwarded. 
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Ai.i'  i^Miiii  nil  si'i  i:iAi  r.n  ;,:;ai.i  nuii.i  '.sini;  hi  iiiiiiii  mi  n  1 1 


3.1. 1 .2.2. 1 


■■'essace  ana  Fcrrat  laentificaticn 


For  input  trarfic  the  F'-'S  snail  ce  capable  uf  accepting,  iaentiTvinc,  anc 
valiuatir.g  ana  ver  i  r'j.  ing  al!  liiessage  'Oi"  ats  ir,trocucea  in  3. 2. 1.2. 1.1. 

3. 2. 1.2. 2. 2  .-'essace  Valiaaticn 

nil  input  traffic  snail  be  subject  to  tne  ivessage  valiaation  requirements 
soecirieo  iii  3.2.i.-.l.a. 

3  .  _ .  1 .  2 . 2 . 3  Sec-.rit7  valiuatiur 

Tne  FXS  shall  perform  security  valiaation  processing  cn  all  input  trarric 
in  accoraance  *itn  tne  oojectives  statea  in  3. 2. 1.2. 1.3.  >vhen  required,  eacn 
logical  terminal  connection  via  the  IAS  network  shall  be  subjected  to  the  same 
level  of  security  processing  as  terminals  airectly  connectea  to  an  I-S/A  AMPE. 

3 . 2 . 1 . 2 . 2 . Error  Processing 

FMS  response  to  errors  oetectec  in  terminal  input  traffic  auring  message 
ana  format  iaeritif ication,  message  validation  or  security  valiaation 
processing  shall  be  governea  by  all  the  factors  introducea  in  3.2. 1.2  (message 
format,  input  circuit,  terniinal  characteristics,  con.inuni ty  of  interest,  and 
error  severity)  in  conjunction  witn  system  settacle  oarameters.  Messages 
containing  errors  cescrioea  in  3.2. 1.2. 1.2  aoove  snail  be  cisplayed  at  an 
I-S/A  AMPE  service  position.  All  detectea  errors  existing  in  the  message 
snail  oe  inaicated  on  the  display.  The  I-S/A  Ai-.PE  snail  process  oetected 
errors  in  accoraance  with  Section  20.  If  tne  message  is  rejected,  the  I-S/n 
mMPE  Shall  automatically  generate  a  service  message  to  tne  originator.  CRITIC 
messages  with  errors  shall  oe  forwaraed,  and  the  originator  shall  be  serviced 
at  tne  Flasn  precedence  level. 

On  a  line  selectable  basis,  basea  on  preaesignated  parameters,  messages 
failing  format  or  neaaer  valiaation  shall  be  automatically  rejected,  in  which 
case  the  FMS  shall  automatically  generate  a  service  message  to  the  originating 
station.  Any  automatically  generatea  service  message  shall  be  of  the  same 
precedence  as  the  rejected  message  except  CRITIC  anu  ECP  which  shall  be  of 
FLASH  precedence.  Messages  with  invalid  precedence  characters  shall  receive 
an  automatically  generated  service  message  with  a  precedence  of  Immediate. 

Processing  of  errored  messages  oetected  auring  security  validation  snail 
be  selectable  on  a  line  by  line  basis  at  the  I-S/A  AMPE.  Two  options  shall  be 
available  for  use  on  controlled  ana  uncontrollea  lines.  On  uncontrolled 
lines,  the  I-S/A  AMPE  shall  receive  the  complete  message  in  which  the  error 
was  detected  but  not  process  the  m.essage  for  aelivery  to  tne  aaaressees 
indicated  on  tne  message.  The  I-S/A  AMPE  shall  automatically  notify  the 
originating  terminal  of  the  error.  On  control  lea  lines,  the  I-S/A  mWPE  shall 
automatically  reject  the  errored  message  and  provide  notification  of  the 
error.  Messages  or  partial  messages  with  security  errors  shall  oe  retained  on 
history  files  until  purge  date. 
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i'lessaoe  ticitiMj  ana  Pre'^aran'cn  Service  ii-':E.PS) 


■•;essage  Ecitiig  ana  Prepararion  Service  .'•.EPS)  sliall  be  available  to-all 
?'•;$  'jsers  ..nest  trarric  is  not  initially  e-ittre-  alreacy  ii^  one  of  cne 
Tk,  1  io.-.'ir.M  final  forn.ats;  u.-i.ep  i:.c,  nSP  1..^,  .oI-lOS,  or  l.oI-103  Sptcial.  Tne 
CLCDut  of  .'-EPS  shall  ce  a  compltce  and  correct  iressage  in  either  oAr.e?  U8  ror 
bfi'.SEP  or  DOI-103  for  DSSCS.  .All  Plain  Language  Address  (PLA)  to  Kouting 
I.-'.cicator  (,RI;  assigninent  s.nall  oc  accoirxlishcC  oy  I-, EPS  portion  of  FPS  (i-EPS 
is  a  subset  or  '•ocule  or  FF.S’ .  r,ll  yEPS  recuireir.ents  are  prescribed  in  3.3.2. 
except  Pt-i  to  RI  Mssignrent  prescriotc  in  o. a. 1.2. 2. 6. 

3. L.. 1.2. 2. 5  Plai.n  Lancuage  Aaoress  IPLAj  to  Routing  Indicator  ,i%I) 

Ass i qnnent 

The  FMS  snail  process  all  originating  traffic  to  perform  plain  language 
acioress-to-routing  inoicator  assignment  when  requireo. 


3 . 2 . 1 .2 . 2 .6 . 1  Formulation  or  Plain  Lancuage  Aggresses 
PLAs  are  formulated  as  follows: 

a.  A  PLA  will  consist  of  an  activity  and  geographical  location 
(city,  case,  camp,  etc.,  and  the  state  and  country),  except  as  noteo  in 

3.2. 1.2. 2. 6. 2. 

(1)  Activity  Title:  An  activity  is  a  unit,  organization  or 
installation  performing  a  function  or  mission.  The  activity  title  can  be 
aobreviatec  in  the  PLA.  The  aobreviations  ano  acronyms  used  in  the  PLAs  are 
centaineo  in  the  PLA  Directory  of  the  appropriate  service  or  agency. 

(2)  Geographical  Location: 

(a)  Cities  will  be  spelled  out  as  tney  appear  in  the 
"International  List  of  Post  Offices",  (Reference  2.5.j).  See  3.2. 1 .2. 2. 6. 2 
for  exceptions. 

(b)  Base,  camp,  station,  etc.,  will  be  abbreviated,  e.g. 
AF6  for  Air  Force  Base,  CP  for  Camp,  FT  for  Fort. 

(c)  The  two  letter  state  and  country  abbreviations  as 
authorized  in  annex  C  of  ACP  198  US  SUPP-1(  )  will  be  used  when  geographical 
locations  are  required. 

b.  A  PLA  will  not  exceed  55  characters,  including  spaces.  Office 
codes/symbols  and  parentneticals  appended  to  a  PLA  are  not  considered  a  part 
of  the  PLA.  Commercial  addresses  are  exempt  from  the  55  character 
liniitation.  The  only  punctuation  authorized  in  PLAs  are  the  hyphen  (-)  and 
decimal  point  (.). 

3.2. 1.2. 2. 6. 2  Use  of  Plain  Lancuaqe  Addresses 


a.  The  PLAs  contained  in  the  appropriate  service  or  agency  Plain 
Language  Adoress  Directory  are  tne  only  PLAs  authorized  for  use  in  message 
addressing  for  activities  listed.  Deviations  in  spellina,  spacing,  or 


in 


'or''.dtt.in9  are  act  aL.:nurircU  anc  shai'i  eiirer  oe  ccrreccec  ir  possTole  'jy  the 
I-j,A  h’t  ooeraior  or  r=:jectcc  oack  to  trie  ;.r'iginacor. 

0.  If  an  act! /it.,  to  ot;  acoressc-  is  act  coiitai.'.^a  ia  a.-i. 

.-'ec  t^r./ ,  t:'e  '"cstace  ..itn  ^a'.j  taat  accrcrjbcc  saall  strat  to  tae  service 
pcs  i  tic  n  or  trie  i“0/r\  m'rc.  ine  acoresset's  title  aao  ceocrapriic  luCeLiu.a 
••.ill  oe  inclucea  iri,  iiec  of  a  PlA,  except  ia  tae  ^.SSCS  c  cn;;:;c  iii  ty.  -a  I-S//- 
.-fPE  eperater  v/ill  i.iase  a  aeteriiiinaticn  as  to  tae  rortacr  electrical 
tracessirc  or  tae  'vessaae  ta..s  e',s..rinc  pr' tectieri  to  all  aocressees. 

c.  jSScS,  .00 1 1  c  aao  ar  loat  ccitiiiarics  at'c  c.<ciipt  i'r'':.t  'jiiac 
ceugrapaicai  Iccatioas  on  their  PLns. 

0.  Activities  whicn  move  to  an  Emergency  Relocation  Site  (ERS) 
Curing  emergency  situations  ana  activities  ivnich  for  security  reasons  -  a 
tactical  consiceration,  are  not  associateo  witn  a  specific  location  are  exemot 
rrem  ..sing  geographical  locations  in  tneir  PLAs. 

e.  Tiie  FXS  snal  i  provice  tne  capability  to  assign  RIs  to  ail  valic 
Pens,  including  Address  Inaicator  Groups  (AIG)  (See  AC?  ICC),  Collective 
nooress  Designator  (.CAOj  (.See  i\TP  3  Supp-l),  Task/Type  organizations  (See  AC? 
112),  general  message  titles  i^See  ACP  121  US  SUPP-1),  DSSCS  Aedress  Groups 
(DAG)  (See  OOI-lOl),  and  proouct  cistrioutions  (See  hSA  Document  USSID  307 
SIGI.hT  Prouuct  Distribution),  If  a  PLA  is  not  containeo  in  the  cata  base  the 
message  snail  be  referrea  to  an  I-S/A  AMPE  routing  management  position  for 
manual  lookup  ana  routing  assignment.  PuAs  on  a  given  message  are  either  all 
GEi'iSER  community  or  all  USSCS  community  PLas,  and  DSSCS  ana  GEnSER  PLnS  snail 
not  be  mixed  in  the  same  message.  A  single  PLA  can,  however,  corresponc  to 
both  a  GEhSER  ana  a  DSSCS  RI.  Suen  a  PLA  is  termed  a  "cuplicatec  P  L A . "  Ahen 
processing  a  ouplicated  PLm  from  an  R/Y  capable  channel,  the  I-S/a  AMPE  snail 
check  tne  other  PLms  of  the  message  and  process  tne  message  as  a  DSSCS  message 
if  any  OSSCS-only  PLAs  are  present.  If  the  message  contains  only  duplicated 
PLAs,  the  message  snail  be  processed  as  a  DSSCS  message  if  the  caveats  in 
format  line  12  so  aictate  (see  DOI-103).  If  caveats  are  not  present,  the 
message  shall  oe  handleo  as  a  DSSCS  message.  DSSCS  processing  incluaes  the 
assignment  of  a  “Y-commun ity"  RI  rather  than  an  "R-commun i ty"  RI,  The  I-S/A 
AMPE  shall  prevent  routing  a  message  to  a  local  addressee  not  cleared  for  the 
security  level  of  the  message  by  crosschecking  the  classification  and  special 
handing  instructions  of  tne  message  with  the  authorized  security  level  of  the 
addressee. 

3 , 2, 1 , 2 , 2, 6, 3  Automated  PLA  Directory  Maintenance 

The  I-S/A  AMPE  operator  shall  be  able  to  make  on-line  update  entries  in 
the  Plain  Language  Address  uirectory  rile. 


i.-.'.i.-.O.-’  r^Lr.  irtiCtOr"'  rlicS 

"•le  r  jv'ectcr_.  riles  sn'.n  in  siancara  rcrjrat  aiiO  crntain  only  P-- 
er'riei  :  i  ir-cr^, 'i  as  li,'e_  ja^'acraa/)  3.1.. _ r.;. 

^....  ]._._. 0.0  ri  16  ‘•'ai nten ance 

' -t  pLr^  cirecrci'v  riias  rea..ii'e  tne  caoaoilit}-  to  be  ccnsrructea,  accsb 

.el-rc'J  ri'-n  :.r.r.  v.-Ciic'^ -.i  ^e  cciriec  in  an  on-line  eiiv  i  r  .orei' .  Provisions 
s.  a.l  I'e  availaole  co  ino tr. ese  noeares  into  tne  s_/Ste!.';  eitner  ror 
i  e.-iarc  on-line  ''CoiriCoticns  cr  oatcne'^.  upoabe  parai'atcrs  lav  oe  orcvioeo 

c.itnin  specially  roniiabieo  text,  -•ii  opoate  aucit  file  snail  oe  iriaiiitainec  at 
eacn  site  to  recora  all  pertinent  cata  ^e.g.,  Time  of  Receipt  for  each  upoate, 
Actual  Time  of  Site  Update,  etc.].  Tiie  data  case  maintenance  proceaures  shall 
not  nave  an  aaverse  eftect  on  system  performance  ie.g.,  degrading  message 
tnrougnput)  and  shall  consider  site  unique  attributes  (e.g.,  peaK  traffic 
times,  nuiroer  of  suoscribers,  etc.).  Local  -PLA  data  base  upoates  will  be  the 
respons ib i 1 i ty  of  tne  I-S/A  AitPE  operation  personnel,  anu  therefore  snail  not 
oe  available  to  remote  sucscribers. 

0.2, 1 .2. 2. 6. 6  Data  3ase  Sizing  For  PLAs 

It  is  estimated  tnat  the  maximum  number  of  PLAs  contained  in  tne  PLa 
directories  xill  De  seventy-five  tnousano  at  IOC,  and  tne  PLA  data  base  shall 
be  designed  to  accommodate  tnis  maximum  and  not  to  preclude  expansion  up  to 
256,000.  The  actual  numoer  of  PLAs  in  eacn  I-S/A  AMPE  directory  vvill  vary 
Trom  site  to  site  and  will  be  determined  by  operations  at  each  site.  The 
following  is  a  listing  of  authorized  Plain  Language  Address  Directories; 

a.  Army  Regulation  105-32,  Authorized  Addresses  for  Electrically 
Transmitted  Messages. 

b.  iNaval  Telecommunications  Publication  (NTP)  3  SUPP-1(  )  Plain 
Language  Address  Directory. 

c.  Air  Force  Manual  10-4,  Air  Force  Directory  of 
Unclassified/Classif ieo  Addresses . 

d.  USMCEB  Book,  Joint  Department  of  Defense  Plain  Language  Address 
Directory  (JDOD  PLAD). 

e.  For  information  concerning  DSSCS  Plain  Language  Addresses,  refer 
to  USSID  505,  USSID  309  and  DIA  Compartmented  Adoress  Book. 
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.2.3 


Inpui  >.essa.':e  Processing  ^.\et'.vcrN ) 


T'le  I-S/n  ,-,'-PE  sneH  oe  c^pacle  of  accepting  IAS  ''ec.vor.k  traffic  frcn;  ’’.■le 
r  r  "a  I  j.cS  s  a  a—  (.  r  ^  c^s  s  '  c  s  er  v  ■  ce  ct  c  t; ic;r  ^  -  a  /  n  .-.'.r  c  s  .  3  l.  cn  t  r  a  r  r  1  c  s  *  i  a  i  • 

CniSliL.  OT  frCtriVcU  aHG  prOCcSScU  OV  tMuSc  ;'i6C.'«Cr.\  i  c!t'i6nt.S  311^^  *  ctl 

SuOSep  jctit  1  V  transiiii  tteu  to  tne  i-S/A  nXPE  for  otlivery. 

Trie  F.'''.Ss  of  any  t.-.o  I-S/^  a'-,?£s  snail  coiT.rrnn i cate  via  logical  ccnnecticns 
esta^'iisnec  oj  tne  rcr"'al  Message  Protccol  iF.'-P)  tnro^^n  tne  !,aS  network. 

o._.i.2.3.i  Icssace  cnc  Fcrrtat  Icentl'icaticn 

network  traffic  shall  be  passec  between  I-S/A  AMPEs  via  tne  FfiP.  The  FMP 
is  to  be  a  nost-to-host  protocol  that  contains  tne  necessary  elements  to 
prevent  shuttling  or  looping  of  messages,  provioes  a  means  for  efficient 
transmission  of  single  ana  multiple  aouresseo  messages  throughout  the  IAS 
network,  ana  inaicates  tne  format  ano  cnaracter  set  in  which  each  message  was 
ori ginatec . 

3 . 2 . 1 . 2 . 3 . 2  Message  ValiaatTcn 

The  FMS  shall  perform  message  valioation  on  all  messages  receivec  from  the 
other  I-S/A  rtMPEs.  The  valication  process  shall  oe  as  specif ieo  by  the 
requirements  or  paragraph  3. 2. 1.2. 1.2. 

3 . 2 . 1 . 2 . 3 . 3  Security  Validation 

The  FMS  shall  perform  security  valioation  processing  on  all  messages 
received  from  otner  I-S/A  mMPEs.  Tne  valioation  process  shall  be  as  specifieo 
by  tne  requirements  of  paragraph  3. 2. 1.2. 1.3.  All  logical  connections  between 
I-S/A  AMPEs  snail  be  subjectea  to  security  validation. 

3. 2. 1.2. 3. 4  Error  Processina 


The  I-S/a  AMPE  shall  have  an  error  processing  scheme  for  message  traffic 
received  from  otner  I-S/A  AMPEs  that  is  consistent  with  paragraph 
3. 2. 1.2. 1.4.  The  objective  shall  be  to  automatically  reject  to  the  originator 
for  correction  any  errored  messages  received  from  other  message  processing 
systems,  with  the  exception  that  CRITIC  shall  not  receive  any  message 
validation  beyond  UW  YEKAAH  ano  is  not  rejected.  Other  high  precedence 
traffic  (FLASH  and  ECP)  shall  be  delivered  if  at  all  possible;  if  not,  it 
shall  be  brought  to  the  immediate  attention  of  an  I-S/A  AMPE  operator  position 
for  the  resolution  of  errors. 

3. 2. 1.2. 3. 5  Looping  Protection 

The  I-S/A  AMPE  shall  protect  against  the  looping  of  message  traffic. 


PRETVIOUS  PAGE 
IS  BLANK 
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Tne  I-S/A  AMPE 
2  i  1  Cm<2  Ai'.PcS 

potential  ’coping  c 
net.vot'\.  1  He  iiidxiiii 


S/A  Ai'lPE  snail  contain  a  looping  protection  scneite  .vhicli  encempass 
3/rt  AAPEs  of  tne  IAS.  Tne  seneme  is  to  protect  against  all 
’coping  contingencies  tnat  mignt  result  front  a  ricnly  conntctea  ImS 
Tile  iiidxin.uiii  nunoer  of  Coces  to  oc  consioereo  snail  oe  2b6  ncces. 


Tne  I-S/n  nAPE  s'nall  nave  tlie  capaoility  to  notify  tne  operator  upon  receipt 
(from  any  cnannel)  of  a  message  tnat  has  oeen  previously  celivereo  to  tne  sanie 
output  destination's).  As  a  minimuni,  the  operator  notification  shall  contain 
icenti f icaticn  of  tne  message  input  ana  output  channels  and  message 
oestinatii-n  celivery  in  forma  ticn  yfcuting  Incicatcrs,  PLA,  etc.). 


,3  A  0  u  t i n  a 


Routing,  as  prescribed  herein,  applies  to  tne  routing  oeterinination  for  a 
single  copy  of  a  message  to  each  intended  recipient  of  the  message.  Subse¬ 
quent  distribution  ana  multiple  deliveries  that  can  be  maae  locally  by  the 
I-S/A  AMPE  are  a  user  service  prescribed  in  3. 2. 1.4. 2,  Terminating  Message 
Process ing. 

3.2. 1.3.1  Routing  Parameters 

Formal  routing  determination  snail  be  basea  on  the  routing  indicators  of 
the  addressees.  The  I-S/A  AMPE  shall  prevent  misrouting  ano  mislabeling  as 
specif ieo  in  DOD  C-5G30.58M,  Ciiapter  2,  para  8  and  10  ano  JaAAP  128  (  ). 
Messages  received  by  tne  I-S/A  AMPE  routed  ano  addressed  to  R — SCC  will 
automatically  have  routing  look-up  performed  for  the  R — SCC  addresses.  The 
I-S/A  AMPE  will  automatically  generate  a  ZOV  for  the  R---SCC  addresses. 

3.2. 1.3.2  Routing  Determination 

The  I-S/A  AMPE  shall  use  a  routing  table  to  determine  tne  destination  for 
each  message.  The  routing  table  shall  contain  the  full  routing  indicator  for 
all  subscribers  served  by  the  I-S/A  AMPE  and  four  or  more  letter  routing 
inoicators  to  cover  all  other  valio  routing  inaicators. 

3.2. 1.3.3  Special  Routing  Considerations 

Messages  containing  a  Collective  Address  Designator  (CAD),  CRITIC 
messages,  and  multiple  addressed  messages  shall  be  provided  special  routing 
considerations: 


3.2. 1.3. 


Collective  Routine 


CADs  consist  of  approved  General  Message  titles  (ACP  117  CAN-US  Supp-1, 
Section  III),  Address  Indicator  Groups  (AIG  -  ACP  100),  DSSCS  Address  Groups 
(DAG  -  DOI  102),  and  those  approved  titles  or  Designators  which  are  assigned 
to  messages  in  format  line  seven.  Each  CAD  will  have  a  cognizant  authority 
responsible  for  the  administration  of  the  CAD  to  include  addition  or  deletion 
of  an  activity  in  the  CAD,  changes  to  the  PLA  of  an  activity  in  the  CAD, 
changes  to  the  activities  in  the  CAD  autnorizeo  to  originate  messages 
addressed  to  the  CAD,  and  aovising  all  concerneo  of  any  changes  to  the  CAD. 
Special  processing  considerations  shall  incluae: 


a.  r  Ri,  R  —  .;a^  oe  t.ie  sa.ic  RI  usee  ror  ccta'"',;rig  PL- 

ic  “  <•  ass  i  9^'^' '.see  Section  i.T?  ane  t  CLsaini’-j  ur-j  cc  “I 

ass ',  ar.n cut .  .■'rssr.:=s  ccnia’.nii’g  a  Cz-J  t'ccaivee  *  an  aLiino.-izeo  5  ,._.scriLer 

snail  ■'i'/e  anc  to  assieoiocnt  i-*error'a*ca  ane  ^'c  pi'oCcSsee  as  a  Multiple 
accressee  v.ailti-ic  RIs  in  fer:;;at  line  Message  tor  eeliverpi  to  all  RIs 

associated  .litn  tne  CAu  in  forraat  lines  seven  anc  eient. 

(1)  .-1 -eressee  RIs  can  be  local  i-MpE  Saoscru-rrs,  rerotr 

i-S/n  nr. Pc  suDsci'i „cr's ,  Or'  nSa  s l<dsc T i oers • 

;e)  Tne  n.TPE  snail  support  botn  Str.'SER  ana  ^bSCS  omDs. 

Tne  assignTent  of  GEilSEk  RIs  to  DSSCS  CADs  ana  vice  versa  shall  oe  prohibitea. 

(3)  A  CAU  may  contain  more  than  five  nuncrea  routing 
inaicators,  however,  for  any  one  aelivery  tne  message  shall  be  limited  to  five 
hunared  RIs. 

b.  Tne  capability  for  tne  I-S/A  A, "PE  to  classmarK  users  (as 
aesignated  by  the  cognizant  autnority  through  the  DCA)  as  authorizec  to  input 
a  particular  CAD,  and  the  capability  to  recognize  and  reject  all  unauthorized 
inputs . 


c.  The  capability  to  generate  TARE  instructions  ana  to  perform 
multiple  aelivery  for  collective  routing  indicators  and  those  basec  upon  T/.pe 
line  information  specifieo  in  format  line  4  of  JAkAP  128(  )  formatted  messages 

d.  The  capaoility  to  recognize  collective  routing  indicators  (RUCk 
or  YECR  in  the  first  four  positions  of  the  RI)  receivea  from  an  ASC  during  the 
transition  period.  These  m.essages  will  contain  a  valid  CAD  in  format  line 
seven  ana  eight  and  will  require  the  same  CAD  to  RI  assignment  as  described  in 
a.  above  with  the  following  exceptions: 

(1)  The  CAD  to  RI  assignment  shall  result  in  the  assignm.ent  of 
only  RIs  ‘or  tne  local  I-S/A  AMPE  subscribers  except  as  described  in  d.{2) 
below.  Local  implies  all  activities  in  a  CAD  which  are  serviced  directly  by 
the  I-S/A  AMPE  in  question. 

(2)  The  assignment  may  include  certain  distant  I-S/A  AKPE 
subscriber  RIs.  This  will  only  occur  during  the  transition  period  in  the 
event  that  the  distant  I-S/A  AMPE  is  not  directly  connected  to  an  ASC. 

(3)  The  assignment  shall  never  include  ASC  subscriber  RIs. 

Since  the  message  containing  the  CAD  was  received  from  an  ASC,  it  can  be 
assumed  that  delivery  has  been  accomplished  to  all  appropriate  ASC  subscribers 

e.  CADs  received  from  a  distant  I-S/A  AMPE  will  already  contain  the 
addressee  RIs  and  will  require  no  special  processing  by  the  receiving  I-S/A 
AMPE . 
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.-A  capaoility  to  recoqnize  ana  prohibit  tiie  niiiltipie  re-er,t'^y  of  a 
C.-Z  b>  a  iucai  autncrizeo  subscriber  rcr  .viiich  ceiivar^,  resoons  ibi  1  i  ty  nas 
been  accctplisnea.  'a-entry,  wnen  necessary,  /<ill  rcc..ire  ..se  if  a  pilot. 

eanerai  Discussion;  During  the  prase  out  of  ASCs  anc  tne  prase  i;  of 
I-S/n  n.'.PEs,  DAD  itanagerr^ent  ',%iri  be  critical  in  ootn  sj-steins  to  insure  tnat 
all  oeliveries  are  properly  accon’olisnea  and  that  multiple  oeliveries  of  the 
same  r.tssace  to  a  single  subscriber  are  precluaed. 


CRITIC  messages  snail  be  processeo  in  accoroance  with  Chapter  2  of 
J0I-lu3.  The  uRITIC  loentif ication,  ww  YEKAAH,  in  format  line  2  shall  be 
detecteo  on  input  and  the  message  shall  oe  routed  without  further  validation. 
CRITIC  acknowleoqments  shall  be  processed  in  accoroance  with  Chapter  2  of 
001-103. 

3.2. 1.3. 3. 3  Multiple  Acdressed  Messages 

Multiple  aooresseo  messages,  requireo  to  be  transmitteo  to  more  than  one 
I-S/A  rl'.PE  in  tne  ImS  network  snail  oe  given  special  consideration.  The  I-S/m 
AMPE  routing  methodology  shall  ce  baseo  upon  an  investigation  of  alternate 
b.etnocs  to  route  multiple  addressed  messages  to  other  I-S/A  mMPEs.  It  is 
possible  for  an  I-S/A  AiMPE  to  open  a  separate  logical  connection  through  the 
LiUw  airectly  to  each  other  I-S/A  AMPE  that  must  receive  the  message.  For 
Output  oelivery  the  I-S/A  AMPE  shall  ina^e  deliveries  oaseo  on  the  terminal 
receiving  one  (1)  only,  up  to  fifty  (50),  or  up  to  five  hundred  (500)  routing 
indicators  per  transmission  at  the  option  of  the  subscriber.  This  requirement 
snail  be  part  of  tne  per  line  parameters  set  at  system  initiation. 

3. 2. 1.4  Output  Message  Processing 

After  the  routing  determination,  messages  shall  be  queued  for  output 
message  processing  as  either  terminating  messages  or  as  network  outgoing 
messages,  or  both.  Network  outgoing  m.essage  processing  is  prescribed  in 
3. 2. 1.4.1;  terminating  message  processing  is  prescribed  in  3. 2. 1.4. 2. 

3.2. 1.4.1  Network  Outgoing  Message  Processing 

Network  outgoing  messages  shall  be  queued  to  the  Formal  Message  Protocol 
module  for  transmission  through  the  ImS  network  (see  ICD  4.2  Protocols)  to 
other  I-S/A  AMPEs.  Each  transmission  of  a  message  to  a  distant  I-S/A  AMPE 
shall  include  only  those  Routing  Indicators  (RIs)  for  which  the  destination 
I-S/A  AMPE  has  delivery  responsibility. 

3. 2. 1.4. 2  Terminating  Message  Processing 

Terminating  Message  Processing  consists  of  message  distribution 
determination,  message  delivery  determination,  security  validation,  and 
message  format  and  code  conversion  as  required. 
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3 _ ' . - _ i  '-'essace  Jisirij’iticn  Function 

_,Cci  -TSirioi/Cion  or  messages  consists  o:  tne  oistri'cuiion 

0-'' ctc-'S  '!■  a  ittssage  se.-.,  orfice  s^.-’'ccl,  sso^ect  icentif ’,0'",  cci  tent 
i:.:'.  tator-  Ok-uvi';  cetermining  tnc  ct'ganizational  ..nits  anc  orrices  .-.hicn  are  to 
reoeisc  tne  message;  oet^rmining  tne  nor.ber  of  copies  reqoireo  for  eacn 
recicient:  ana  afrixing  tne  aistr ibotion  informat icn  to  the  beginning  of  the 
mcssaoe  nOP  laJ  oS  SuPP-1/.  Tne  I-S/A  .-.''PE  snali  -ao tomat ica  1  "ly  aetermine 
i  i  t:' 1  Jo  t  i  an  tor  criginatinc  anc  terminating  trarric. 

3  . c. .  1 . -  . 2 . 1 . 1  oist'^ipotion  Jetermination  Parareters 

The  aetermination  of  units  and  offices  which  shall  receive  distribution  of 
a  particular  message  shall  be  baseo  on  the  following  parameters: 

a.  Destination  Station  Routing  Indicator  (OSRI) 

b.  Plain  Language  Acoress  ^Guaraeo  and  Protecteo)’'  inducing  AI6s, 
etc . 

c.  Office  Symbol /Wumoer 

c.  oontent  Inoicator  Cooe  (CIC) 

e.  Icentifier  Coue  ;  NmTO  Subject  Icentirier  (NASIS),  Stancarc 
Subject  Identification  Coce  iSSIC), 

r,  F lagworc/Keyivorc  in  first  eight  lines  of  text 

g.  Message  references,  both  incoming  anc  outgoing,  (in  first  seven 

lines  of  text  or  down  to  first  paragraph  on  JAAAP  128) 

h.  Status  OT  message  recipient  -  Action  or  Info  Aocressee 

i.  Drafter  Designators  for  local  distribution 

j.  Source  (Incoming  channel  -  e.g..  Optical  Character  Reader) 

K.  Precedence 

l.  Classification 

m.  Reference  Routing 

n.  Originating  Station  Routing  Inoicator  (OSRI) 

0.  Delivery  Distribution  Inoicator  (GDI) 

*The  term  "Guard"  means  the  I-S/A  AMPE  shall  determine  internal  office 
distribution  to  specif iec  organizations.  "Protect"  means  the  I-S/A  AMPE  shall 
provide  a  set  number  of  copies  to  an  organization,  which  in  turn  arranges  for 
its  own  internal  distribution. 


anc  Litiic  aeter,'’iiiaLion  snail  not  oe  porro»“.neG  for  aata 


▼ 


'iOTE:  C'flce 
patcern  xess^ges  . 

J,_.  I  • .  1 . i-  u  1  s t r i 0 LI u ’) on  Ct^ttr^iinazi^n 

Each  unit;  snail  nave  the  capabilic}'  to  specify  any  or  all  of  tne 
paraireters  in  3 . 2. 1  .  2  . 1 .  1  that  snail  oe  usee  in  cetcrniining  hi  siriouiicn . 

Tnese  parait.eters  represent  miniT.u"  criteria  arc  rtiay  Oc  ^sec  incivi-L.a :  ly 
ar.c/cr  collectively  to  oeter-nine  aistricuticn.  Aoai  ticnal  ly.  each  unit  inall 
na;e  tne  capaoility  tc  prioritize  tite  use  cr  tnese  paraiueters .  Tacla 

3.2. 1  .-.2. 1  .a  illustrates  tne  use  of  t.nese  parameters  tor  oE'.SER  anc  l-SSCS 
formats.  Delivery  Distribution  Inaicators  (CDI)  are  specirieo  in  USSID  519. 

At  IOC  the  I-S/A  AMPE  snail  support  the  existing  Service  and  agency 
distribution  scherres. 

3.2. 1 .4.2. 1 .2. 1  Correcack-Cooies  of  rlessaaes 

The  I-S/A  AMPE  shall  provioe  tne  automatic  capability,  invoked  at  tne 
I-S/A  AMPE  at  tne  option  of  tne  subscriber,  for  either  no  comeback  copy  or  for 
one  of  the  follovving: 

a.  Providing  to  the  originating  subscriber  a  comebacx  copy  of  each 
originated  message  in  the  transmitteo  format  including  the  unique  message 
identifier. 


b.  Providing  to  tne  designated  terminal  position  an  acknowledgment, 
to  include  the  date-time-group  and  unique  message  identifier,  rather  than  a 
display  or  printed  copy  of  the  entered  message. 

3.2. 1 .4.2. 1 .2.2  Multiple  Copy  Determination 


The  number  of  copies  of  each  message  to  be  distributed  to  each  unit  anu 
office  shall  be  determined  automatically,  based  on  message  subject, 
classification,  ana  status  (either  action  or  info).  Each  unit  ano  office 
shall  be  able  to  specify  the  number  or  copies  that  each  combination  of  the 
aforenamed  parameters  dictates.  The  number  of  copies  and  the  distribution 
shall  be  annotated  on  the  first  page  of  tne  copy  delivered. 

3.2. 1.4. 2. 2  Message  Delivery 

The  I-S/A  AMPE  shall  deliver  messages  to  local  subscribers.  For  each 
message  the  I-S/A  AMPE  snail  determine  wnat  deliveries  are  to  be  mace,  hew  to 
make  each  delivery,  and  what  format  is  requireo  for  each  delivery.  Tne  I-S/A 
AMPE  shall  automatically  deliver  each  message  to  the  appropriate  interface, 
based  on  the  parameters  specified  below.  If  tne  I-S/A  AMPE  is  unable  to 
deliver  a  message  automatically,  the  message  shall  be  sent  to  an  operator 
position  to  allow  for  operator  intervention. 
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3 C . 2 .  !  r'essace  L/elivery  P ara.'i'eters 

Tne  r'c  I  iw.vvic  -iie's  are  jsea  to  aeter:r.ine  the  aelivcry  destinaticn  of  a 
■•essacc; 

a.  Destination  Station  Routing  Incicator 

t.  Plain  Language  Aocr^ss  (Short  Title) 

c.  .-rite  Sytcol 

G.  Content  InGicatcr  Coce 

e.  Icentirier  Cooe  (See  3.2. 1 .4.2. 1 . 1 .e) 

*■' .  F lacwora/Keyword  in  first  eight  lines 
or  format  line  12 

g.  Source 

n.  Language  Meoia  Format 

i .  Preceoence 

j.  Action/ Info  nccressee  Status 
<.  TmkS  Line 

l .  Operating  Signals 

m.  Classification 

n.  Transmission  Release  Codes  (TRC) 

0.  Transmission  Control  Codes  (TCC) 

p.  SPECAT  Release  codes  (SPECAT 
Handling) 

q.  Celivery  Distribution  Incicator 

r.  Orginating  Station  Routing  Indicator 

s.  Special  Handling  Designators  (SHD) 

3.2. 1 .4. 2. 2. 2  Message  Delivery  Determination 

Based  on  the  parameters  identified  in  paragraph  3.2. 1 .4.2.2. 1 ,  messages 
shall  be  electrically  aeliverea  to  any  or  all  of  the  following:  a 
communications  center  local  device,  a  remote  terminal (s ) ,  ano/or  a  service 
position.  Tables  3.2. 1 .4.2.2. 2->l  and  3.2. 1 .4. 2. 2. 2-2  illustrate  the 
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iNOTE :  To  obtain  office  symbol  for  guaraea  PLAs,  search  must  be  conducted 
on  other  fields  (i.e,,  Flagword,  ID  code,  etc.) 

DEFIMTIONS 

Local  Delivery  -  Position/Station  within  the  confines  of  the  I-S/A  AMPE 
Telecommunication  Center  (e.g.,  printer,  Video  Display  Terminal) 

Subscriber  Terminal  -  Hardware  device  located  outside  of  the  I-S/A  AMPE 
Telecommunication  Center 


Service  Position  -  Station  located  within  the  I-S/A  AMPE  Teleconmun ication 
Center  used  to  correct,  edit,  or  verify  messages. 
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cciv:;  iridiion  at  uenvt''y  pararrecers  for  GlE^ScR  narrative  atiu  G.;‘:a  pattern 
•estates,  as  ..di  as  ES3CS  narrative  ana  cata  pattern  ir.essaaes.  These 
^ar^.etcr.-  represent  the  criteria  netcec  ta  effect  aeiivery.  '"ney  may  pe  nsec 
i  n c  ’  / 1  c vj :  i  i y  ar  j or  c  y  1 1 cC t  i e  1  y  t c  ec t erit i cie  ce  i  i  very . 

3.^.1. -^.2. ^.3  teC-yrity  Vaiiaation 

Tne  I-S/rt  rt'-.PE  shall  assure  tnat  eacn  cevice  is  authurizec  (accorcing  to 
Security*  level  to  receive  a  itessace  prior  tu  ceii.-er_,  or  that  r-.essage  to  the 
-evite  'See  3. ..a. 2  ana  3. a),  delivery  of  SrSte.T  -ressages  snail  ce  in 
ac Cu r i- ui' i- i  .',itn  paracrapir  aaZ,  aCP  1p1,  oS  SoPP-l(c). 

3.2.  l.h.a.Z.*!  Format  Canversion 

The  I-S/m  AMP£  shall  be  capable  of  converting  messages  to  any  of  the 
rorir.ats  uescrioea  in  ICO  paragraph  4.3.  These  formats  shall  oe  selectable  for 
each  input  or  output  device  or  line. 

3.i..  1 .4.C.2.5  Xeaia  Conversion 

Tne  I-S/A  AiXPE  snail  be  capable  of  converting  messages  for  output  to  card, 
narocopy,  paper  tape  (havy  requirement),  magnetic  tape,  or  any  combination, 
ror  over-the-counter  celivery,  or  electrically  aelivering  tne  information  to  a 
remote  cevice  using  the  language  meoia  formats  oescrioea  in  Annex  A  to  JA.NrtP 
123(H),  001-105  anc  DCAC  370-D175-1.  Reference  2. 5. a.  Chapter  4  Section  II 
oescribes  format  ano  meoia  conversion  as  currently  implementeo  in  ASCs,  ano 
may  be  useo  as  a  guice. 

3.2. 1 .4. 2. 2. 6  r'essage  iTeoia  Services 

Tnese  services  encompass  those  areas  which  format  a  message  in  accordance 
with  user  requirements.  These  capabilities  shall  be  inoividually  selectable 
by  each  user  terminal.  The  I-S/A  AMPE  shall  provide  each  of  the  following 
services  automatically. 

3 .2 . 1 .4 .2.2. 6. 1  Distribution  Identification 

Each  message  delivered  to  the  collocated  Telecommunications  Center 
terminal  for  over-the-counter  delivery  shall  list  the  offices  that  have  been 
identified  as  message  recipients  and  the  number  of  copies  of  the  message  they 
are  to  receive,  ms  an  operator  selectable  option,  individual  deliveries  shall 
include  only  the  distribution  information  pertinent  to  the  users  served  by 
that  delivery. 

3.2. 1 .4. 2. 2. 6. 2  f’lessage  Identification 

The  following  shall  also  appear  on  each  page  of  the  message:  Time  of 
receipt;  Ordinal  aate,  hours  and  minutes;  message  precedence  at  the  top  and 
bottom;  unique  message  identifier;  and  Classification,  Special  Handling 
uesignations,  and  Message  Handling  Instructions  oelimited  by  asterisks  on  the 
top  and  bottom  center. 
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3 . 2. 1 . 4. 2 .2 .6. 3  Eai ting 

Tne  I-S/A  AMPE  shall  nave  tne  capability,  selectable  by  channel,  to  st-io 
cctrcni cations  inforniation  by  foriiiat  line  ^FL)  beginning  with  FLl  rniining 
tnrougn  11  ana  from  FL13  running  thrcugn  15  rroin  the  message  and  to  ccubio  o.' 
single  space  the  message. 

3.2.1. -+.2. 2. 6. 4  Print  Expansion  of  Reports 

7'ie  I-S  n  nXPE  snail  have  tne  capaoility  to  perrorm  print  expansion  for 
,-'-.rTiy  SiuPERS  reports  as  specified  in  tne  iC3  Appenci.x  B. 

3.2. 1 .4. 2. 2. 6. 5  Classification  Display 

The  I-S/A  AlfPE  sitall  label  all  display  screens  with  the  classification  or 
tiie  message  or  data  being  aisplayed.  This  shall  also  apply  to  information 
assoc  i  a  tea  ,vith  messages  or  cata  wnen  it  is  displayed. 

3.2.1 .4. 2. 2. 6. 6  Special  Print  Out  Requirements 

.vnere  requireo  (oetermineo  on  a  site-by-site  oasis)  the  I-S/A  AMPE  shall 
print  out  messages  in  both  eaitea  and  uneoiteo  format  as  follows:  messages 
printeo  on  tne  "Message  Center"  printer  shall  be  in  eciteo  format;  messages  on 
tne  "Service  Center"  printer  shall  be  in  unedited  format.  Both  formats  nave 
soti.e  things  in  common.  The  classification  and  special  handling  instuctions 
(caveats  and  codewords)  shall  be  printeo  at  the  top  ano  bottom  of  each  page. 
Operating  signals  and  content  indicator  codes  are  inoicated  at  the  top  of  the 
first  page,  oeneath  the  classification.  Above  the  classification  at  the 
bottom  of  the  first  page  are  printed  the  local  distribution  lines  (OTC 
delivery,  if  any),  a  chop  line  indicating  routing  method  and  controlleo 
routing  for  TS  and  SPECAT  classification  messages,  ano  a  control  line 

containing  UMI,  input  CSN,  page  count  ( _  of  _  pages),  ano  UTG.  Tiie 

remainder  of  each  format  is  described  below. 

(1)  Unedited.  Uneoited  format  consists  of  each  line  of  the  message 
printed  exactly  as  received.  No  attempt  shall  be  maoe  to  clean  up  the 
printout.  In  addition  to  the  text  and  lines  oescribed  above,  the  unedited 
format  shall  include  any  service  lines  generated  by  the  processing  routines. 
These  lines  shall  be  printed  on  the  first  page  between  the  chop  line  and  the 
control  line. 

(2)  Edi ted.  In  edited  format,  message  format  lines  1,  2,  3,  4,  43, 
10,  11,  14,  15,  16,  and  any  paging  lines  shall  be  deleted.  The  precedences 
shall  be  printed  as  words  above  format  line  5.  Format  lines  7  through  9  shall 
be  printed  as  two  addressees  per  print  line  with  RIs  deleted,  if  the  addressee 
short  titles  are  short  enough.  Blank  lines  shall  be  printed  between  the 
precedence,  format  lines  5  through  9,  format  line  12,  and  any  paragraphs. 

3.2. 1 .4. 2. 2. 7  Data  Pattern  Delivery  Processing 

Data  Pattern  messages  shall  be  identified  by  destination  Language  Media 
Format  (LMF)  codes  B,  C,  D  or  I.  The  I-S/A  AHPE  shall  have  the  capability  to 
either  queue  the  data  pattern  traffic  for  subsequent  delivery  (e.g.,  retained 
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for  li.  nours )  selectaole  oy  cne  of  tiic  parciineters  specif  ieo  beicw  ur  process 
for  irri.ieci ate  delivery. 

3 .  Z  .  1 . -1 . 2 . 2 . 7 . 1  L/ata  Pattern  ...elivery 

The  suDScri'oer  snail  be  aole  to  specify  that  the  I-S/^a  A'-'.PE  will  select 
Djlk  oata  pattern  trafric  via  tne  following  parairieters : 


a  • 

Routing  Incicatcr  (RI) 

b . 

Language  Meaia  Format 

IMF) 

^  • 

Content  Inaicator  Code 

(CIC) 

d . 

Text  header  (TXTHCR) 

e . 

Classification 

Any  mix  of  caru  punch,  magnetic  media  ano  line  printer  shall  be  aole  to  be 
specified  for  the  output  aevice(s). 

5.2. 1 .4. 2.2.7 .2  Uata  Pattern  Sections 

Tne  I-S/A  AMPE  shall  provice  four  options  for  the  receipt  of  oata  pattern 
messages  that  are  secticnea  (see  paragraph  501  JANAP  123).  The  options  snail 
be  selectable  by  each  subscriber.  The  options  are: 

a.  Option  1  -  (default  option)  Message  sections  are  released  for 
delivery  to  the  subscriber  as  soon  as  received. 

b.  Option  2  -  Message  sections  are  released  for  immediate  delivery 
to  the  subscriber  if  received  in  the  correct  sequential  order;  if  received  out 
of  order,  the  message  section(s)  shall  be  held  until  the  previous  message 
section(s)  are  received,  the  sections  shall  then  be  released  in  message 
section  number  order. 

c.  Option  3  -  All  message  sections  shall  be  held  until  all  sections 
are  received;  the  sections  shall  then  be  released  for  delivery  to  the 
subscriber  in  message  section  number  order. 

d.  Option  4  -  It  shall  be  possible  to  hold  the  data  pattern  traffic 
for  delivery  on  a  designated  time  schedule  or  released  by  the  I-S/A  AMPE 
operator  at  the  request  of  the  terminal. 

The  I-S/A  AMPE  operator  shall  have  the  capability  to  override  options  2 
ano  3  and  release  individual  message  sections  for  delivery. 


3.2. 1.4. 2. 3  Output  PI  Classmark inq 

For  output  delivery,  I-S/A  A>\PE  subscribers  shall  have  the  classmarx 
option  of  receiving  1,  50,  or  bOO  RIs  per  transmission;  e.g.,  should  a  message 
containing  10  RIs  be  destined  for  a  subscriber  classmarked  to  receive  one  (1) 
RI  per  transmission,  the  AMPE  must  make  10  transmissions,  one  for  each  RI. 


3.<i.l.5  f'lessaae  Processinq  Control 


3.2. 1.5.1  Prececence  Processing 

I'-.essages  snail  oe  processea  Firsi-In-First-Out  (FIFO)  within  each 
prececence  category  (See  3. 2. 3. 2. 4)  with  tne  following  exceptions: 

a.  Service  iiiessages  shall  be  placed  at  the  heaa  of  the  appropriate 
precedence  queue. 

0.  Tne  nl-.PE  snail  nave  tne  capability  to  manage  tne  strict  FIFO  by 
precedence  (liessage  processing  such  tnat  no  one  community  of  users  (OSSCS, 
GEhSER)  can  monopolize  tne  available  transmission  media.  To  prevent  such 
monopolization  on  dual  community^channels,  a  4-to-l  channel  allocation  ratio 
shall  be  applied  such  that  at  least  one  DSSCS  flash  and  above  precedence 
message  is  transmitted  on  a  given  dual  community  channel  for  every  four  GEiMSER 
flash  and  above  messages  transmitted.  Another  4-to-l  cnannel  allocation  ratio 
snail  apply  to  these  same  cnannels  for  immediate  precedence  messages.  DSSCS 
messages  will  not  be  delayed  to  achieve  the  4-to-l  ratio.  FIFO  within  each 
precedence  will  apply  unless  enough  GENSER  rriessages  are  on  queue  anead  of  the 
DSSCS  messages  to  bring  the  cnannel  allocation  ratio  into  effect.  Operator 
notification  of  high  precedence  DSSCS  traffic  shall  be  performed  in  accordance 
with  DoD  C-5030-5Si'i,  Chapter  4,  paragraph  7  and  DOI-103. 

c.  For  GEiNSER  traffic  only,  tne  I-S/A  AMPE  shall  process  messages 
with  designated  Content  Indicator  Codes  (CICs)  (not  to  exceed  ten  different 
cooes)  prior  to  other  messages  of  the  same  precedence. 

d.  Overflow  conditions  as  specified  in  para  3. 2. 1.5. 4. 

e.  Queue  Management  as  specified  in  para  3. 2. 1.5. 6. 


.2. 1.5. 2  Message  Preemption 


Message  preemption  means  ceasing  to  process  the  current  message  on  the 
output  queue  and  commencing  to  release  the  preempting  message.  The  I-S/A  AMPE 
shall  nave  the  capability  to  preempt  the  output  of  a  message  to  allow 
transmission  of  a  specified  higher  precedence  message;  preemption  shall  not 
cause  the  loss,  modification,  or  segmentation  of  a  message.  ECP,  CRITIC  and 
Flash  messages  shall  automatically  preempt  lower  precedence  messages.  If  a 
message  is  preempted  during  transmission,  the  I-S/A  AMPE  shall  cancel  the 
message  and  place  the  preempted  message  at  the  head  of  that  precedence  queue. 
If  a  message  with  a  channel  sequence  number  is  preempted  during  transmission, 
a  CAi\TRAN  shall  be  sent  and  a  new  channel  sequence  number  shall  be  assigned 
prior  to  reinitiating  transmission  of  the  preempted  message.  For  DSSCS 
traffic  all  messages  cancelled  shall  be  terminated  with  a  CANTRAN  sequence. 

Tne  message  shall  not  be  preempted  if  the  end  of  message  process  is  active. 


1.5.3  Automation  Assisted  Traffic  Management 


This  function  encompasses  all  those  automatic  and  I-S/A  AMPE  operator 
interfaced  operations  which  control  flow  and  processing  of  message  traffic 
through  the  I-S/A  AMPE.  These  operations  induce  traffic  loading,  generating 


cfio  processitig  service  iressages,  aitrouting,  intercept  processing,  overflow 
protection  ana  prececence  processing. 

3 . ^ .  1 . 0 . 3 . 1  Trarfic  Loaaing 

The  designatea  syste.t  operator  shall  have  the  capability  to  visually 
inspect  tne  status  of  the  queues  on  any  specified  channel.  When  the  queue  of 
:tessaqes  for  any  channel  readies  a  predefineo  threshold  (set  oy  the  I-S/A  AMPE 
operator),  tne  system  shall  generate  a  notice  of  tne  queue  condition  ano 
display  this  notice  at  tne  designated  operator  position.  Mcoitional ly,  system' 
status  inronration,  see  3.3,  snail  be  available  to  the  operator. 

3.3. 1.0. 3. 2  Message  Timing  and  Overdue  Notifioation 

The  system  shall  perform  message  auditing  beginning  at  the  time  of  receipt 
of  the  message  EOM  and  shall  notify  the  system  operator  if  the  time  the 
message  has  oeen  in  the  system  exceeds  a  preoeterminea  time  threshold.  A 
message  is  considered  to  be  in  the  system  as  long  as  the  I-S/A  AMPE  has 
delivery  responsibility,  i.e.,  until  the  I-S/A  AMPE  has  completed  transmission 
of  tne  message  to  all  required  channels  ana  an  acknowledgment  has  been 
received  for  messages  requiring  it.  (Exception:  messages  on  intercept  are 
excluded  from  this  overdue  notification  until  they  are  returned  to  active 
processing.)  A  message  is  considered  overdue  when  the  following  time  limits 
are  exceeded: 


Precedence 

Time 

In  System 

a.  Flash  and  above 

1 

minute 

b.  Immediate 

5 

minutes 

c.  Priority 

30 

minutes 

d.  Routine 

80 

minutes 

If  any  of  the  time  limits  noted  above  are  exceeded,  the  system  shall 
provide  an  operator  notification  to  the  system  operator.  The  overdue 
notification  shall  include  the  message  OSRI-OSSN,  system  assigned  unique 
message  identifier,  precedence  and  destination  channel  designator.  The 
operator  shall  be  notified  of  high  precedence  messages  every  five  minutes 
until  delivery.  If  multiple  messages  of  the  same  precedence  are  overdue  only 
the  oldest  message  for  the  precedence  shall  be  identified.  The  operator  will 
be  responsible  for  the  action  to  be  taken,  i.e.,  altroute,  reset  overdue 
threshold,  ignore,  etc.  The  overdue  time  limit  shall  be  able  to  be  reset  by 
the  operator  for  immediate,  priority  or  routine  messages  to  a  maximum  of  99 
minutes.  Flash,  ECP  and  CRITIC  thresholds  shall  not  be  able  to  be  reset. 

The  I-S/A  AMPE  shall  be  capable  of  generating  an  I-S/A  AMPE-to-I-S/A  AMPE 
receipt  for  each  CRITIC  received  from  a  distant  I-S/A  AMPE  indicating  that  the 
CRITIC  message  has  been  received  and  delivered.  The  I-S/A  AMPE  shall  also  be 
capable  of  suspensing  receipts  expected  from  a  distant  I-S/A  AMPE  following 
CRITIC  transmissions,  and  when  not  received  within  specified  time  periods 
(software  selectable  not  to  exceed  60  seconos  maximum),  automatically  select 
secondary  or  tertiary  routes  for  delivery. 
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3 . 2 . 1 . 5 . 3 . 3  Inte rce Dt  Processing 

Intercept  processing  shall  provide  operator-initiated  interim  storage  for 
massages  -.vnose  delivery  is  delayed  by  an  inoperative  or  bachlogged  output 
channel.  Using  intercept  the  I-S  'A  A^-IPS  shall  be  able  to  temporarily  hold 
messages  for  a  destination  which  is  partially  or  completely  out  of  service  or 
which  operates  on  a  part-time  basis.  The  I-S/A  AMPE  shall  provide  the 
capability  to  invoke  and  revoke  intercept  by  system  operator  specification  of 
combinations  of  the  following  criteria:  PLA,  precedence,  routing  indicator, 
channel ,  security  classification,  and  language  media  format.  ECP,  CRITIC  and 
Plash  and  sei-.’ice  messages  shall  not  be  intercepted  but  shall  be  delivered  to 
the  ope  ator  for  further  processing  that  will  result  in  the  delivery  to  the 
required  PLA.  Immediate  precedence  and  below  shall  be  intercepted,  when 
initiated,  with  notification  printouts  for  each  occurrence.  FIFO  within  each 
precedence  level  shall  be  maintained  for  the  selected  intercepted  messages 
being  returned  to  the  I-S/A  AMPE  output  queues. 

3. 2.1.5. 4  Overflow  Protection 

An  overflow  condition  exists  when  the  combined  message  input  load  exceeds 
the  capacity  of  the  I-S/A  AMPE  to  process  that  message  load.  '.'Jhen  an  overflow 
condition  occurs,  the  most  recently  received  and  lowest  precedence  messages 
shall  be  automatically  stored  in  an  overflow  storage  file.  '■Jhen  the  message 
load  permits,  messages  stored  in  the  overflow  file  shall  be  automatically 
reintroduced  for  processing  in  accordance  with  FIFO  criteria  (See  3. 2. 1.5.1). 
The  operator  shall  be  notified  automatically  of  message  movement  to  and  from 
overflow  storage.  CRITIC,  Flash,  and  Emergency  Command  Precedence  messages 
shall  not  be  stored  in  overflow  storage.  The  operator  shall  have  the 
capability  to  manually  reintroduce  messages  from  the  overflow  file  for 
processing,  and  to  inhibit  input  from  designated  input  channels.  Criteria  for 
message  overflow  shall  be  channel  activity,  queue  load  by  addressee, 
precedence,  or  a  combination  of  these.  Message  processing  shall  continue  on 
active  channels  during  the  overflow  condition.  Adherence  to  the  provisions  of 

3.4  shall  continue  during  overflow  conditions. 

3 . 2 . 1 . 5 . 5  Alternate  Routing 

The  I-S/A  AMPE  operator  shall  be  able  to  invoke  an  automatic  altroute  for 
traffic  destined  to  one  of  the  I-S/A  AMPEs  local  subscribers.  The  I-S/A  AMPE 
shall  automatically  generate  a  pilot  consistent  with  the  message  format,  with 
the  appropriate  Routing  Indicator,  and  forward  the  message  to  the  new 
destination.  The  I-S/A  AMPE  operator  shall  have  the  capability  to  further 
identify  messages  to  be  altrouted  by  designating  the  addressee  and  any 
combination  of  one  or  more  of  the  following:  precedence,  classification, 
language  media  format,  and  content  indicator  code.  See  3.4  for  security 
restrictions  and  3.3.3  for  additional  requirements.  The  I-S/A  AMPE  shall 
automatically  generate  and  transmit  a  service  message  notifying  the 
destination  of  its  altroute  status  prior  to  transmitting  the  first  altrouted 
message.  It  shall  also  automatically  generate  and  transmit  a  ser^/ice  message 
upon  terminating  the  altroute  condition. 


1.5.6  Qiie'j6  ’’an jceircnt 


T- e  I -S/A  A.'-.PE  cperaicr  sn-ll  nave  the  capaDility  to  inspect  anc 
’■.an  i  P'..  I  ate  /.essace  pucses  as  a  cans  ac  alleyiatc  processing  bacslcgs.  Tne 
operator  snail  cc  .aole  to  iranbrcr  entire  queocS  lo  aitertiate  cnantiel  CLeues 
r^r  cel i very,  move  incivicual  r^essages  to  alternate  queoes  or  airferent 
positions  '.vitnin  tneir  current  queues,  or  remove  messages  rrom  the  processing 
rl^.N  entirely  oy  placing  tnem  on  intercept.  In  accicion  the  operator  shall  be 
^roviccj  tne  capaoility  to  purge  a  speciric  iressage  (causing  malfunction  oue 
tu  cata  sensitive  soft.-.are  errors]  frem  the  queue.  Tre  acoitional  capability 
tc  purge  ttie  entire  system  message  riles  snail  be  proviceo,  inclueing 
sareguaros  tnat  prevent  accioental  purging  or  purging  oy  an  unauttior izea 
individual,  i-’essage  icentif ication  shall  oe  provided  to  the  I-S/A  AMPE 
operator  to  allow  for  subsequent  recovery  action  on  the  purged  ir.cssage(s ) . 

5 . 2 . 1 . 5 . 7  Automated  Routing/Distribution  File  [Maintenance 

Tne  I-S/A  AMPE  shall  be  able  to  semi-automatical ly  process  changes 
rtceiveo  for  tne  routing  and  Distribution  files.  Tne  changes  shall  not  be 
mace  to  the  file  until  the  I-S/A  AMPE  operator  has  reviewed  tne  change  and 
mace  a  positive  manual  action  to  enable  tne  cnange  to  be  posted. 

5. 2. 1.5. 8  Service  Messages 

Service  messages  are  concise,  and  normdly  precisely  formatted,  messages 
used  oy  communications  personnel  to  exchange  information  ana  instructions 
concerning  conduct  of  communications.  In  all  cases,  service  messages  shall  be 
processed  to  preclude  the  possibility  of  compromise  of  classified 
information.  The  I-S/A  AMPE  shall  automaticdlly  generate  and  deliver  service 
messages  in  accoroance  with  formats  specified  in  JANAP  128,  ACP  127  ano 
001-103  updn  detection  of  errors  and  as  otherwise  appropriate  (e.g.,  on 
invoKing  and  revdking  alternate  routing).  A  list  of  the  service  messages  to 
Oe  involved  by  the  I-S/A  AMPE  are  specif ieo  in  Section  21.0. 

3.2.1 ,5.8.1  System  Generated  Service  Messages 

System  generated  service  messages  are  those  originated  within  the  I-S/A 
AMPE  system  itself,  rather  than  being  entered  from  a  terminal  or  prepared 
manually  by  an  I-S/A  AMPE  operator  and  entered  through  a  terminal.  System 
generated  messages  shall  be  initiated  by  either  operator  command  or 
automatically  in  response  to  the  following  types  of  conditions:  invalid 
channel  designator,  invalid  channel  sequence  number,  open  channel  sequence 
number,  invalid  routing  field,  invalid  security  fiela,  invalid  transmission 
release  code,  invalid  header,  invalid  end-of -message  sequence,  invalid 
transmission  control  code,  overlength  message,  suspected  stragglers,  input 
message  timeout,  acceptance  or  transmission  of  a  high  precedence  message  and 
an  excessive  number  of  routing  indicators  in  the  routing  field.  A  complete 
listing  of  required  service  messages  is  detailed  in  Section  21.0,  Service 
Message  Appendix,  The  I-S/A  AMPE  shall  automatically  generate  a  channel 
continuity  verification  (JANm?  128  para.  329.e.(16))  when  30  minutes  have 
elapsed  with  no  receipt  of  traffic  from  a  Mode  11  subscriber.  Adoi tional ly, 
messages  which  require  receipt  of  acknowledgment  by  the  communications  center 
(as  opposed  to  acknowledgment  by  the  user,  which  must  be  done  only  by  the 
user)  shall  be  automatically  processed  by  the  I-S/A  AMPE  to  include 
acknowledgment.  The  I-S/A  AMPE  shall 
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also  3i,:o:naiic3l  ly  ac^nc.v  <eoge  receipt  oy  routii:e  prececence  message  tor 
Flasn,  £C?  ana  CRITIC  r:ess3ges.  See  Section  Cl  for  a  iistir, i  cr  service 
■tessaces.  tneir  description  ana  use.  ^rcererence  2. 5. a,  (-ppercix  b.  Section  I 
-cscrioes  no.v  tnis  recai  :'-:::ent  is  satisrieo  oy  nSCs  anu  ..ay  ..seu  as  - 
ou i oe .  1 

Tne  I-S/n  miVPE  operator  snail  receive  a  copy  of  system  generatea 
..'.essages.  In  aouition.  tne  systcn  snail  oe  so  cesignec  that  all  system 
generatea  ."=ssages  are  rtcorcec  ^n  tne  nistory  reccrc. 


0.0.  1.0. ^.2  rvutOtiiateG  Prcoessino  ct  ter  vice  I’essaces 

Service  messages  receiveo  from  sucscribers  which  require  retransmission  of 
messages  stored  online  snail  be  automatically  processea  by  the  I-S/A  AMPE,  to 
incluoe  automatic  retrieval  and  retransmission  of  the  requestea  message{s). 

Tile  automatic  response  to  service  messages  will  require  close  control  cue  to 
security  anc  privacy  consioeraticns;  that  is,  tiie  subscriber  requesting  the 
retransmi ss ion  of  a  niessage  must  oe  authorizea  to  act  as  an  originator  of  suen 
a  n.essage  as  well  as  being  eitner  the  originator  or  an  addressee  on  the 
subject  message.  The  I-S/n  mMPE  shall  also  automatically  process  requests  for 
retransmittal  by  Channel  Sequence  huincer  and  time  perioo.  If  a  retransmission 
request  is  for  more  than  10  messages,  it  shall  be  forwaroed  to  tne  I-S/A  AMPE 
operator  for  approval.  If  a  message  cannot  oe  retrieved  automatically,  the 
I-S/A  AMPE  operator  shall  be  notified  of  all  information  to  permit  manual 
retrieval  of  the  message  if  required. 

3. 2. 1.5. 8. 3  Manual  Processing  of  Service  Messages 

All  incoming  service  messages  which  are  not  automatically  processed  by  the 
I-S/A  AMPE  Shall  be  aelivered  to  the  Designated  service  position  for  manual 
intervention  except  that  service  messages  destined  for  designated  terminals 
(e.g.,  a  Mavy  RIXT  or  Army  IRT)  shall  be  delivered  to  the  designated 
terminals.  The  service  position  shall  have  the  capability  to  perform  message 
eoiting  of  service  messages,  attach  pilots  to  the  messages,  readdress  messages 
ano  call  service  message  masKS  (JANAP  128,  DOI-103,  ACP-127)  to  the  display 
for  insertion  of  variaole  information  and  release  of  messages.  Tiie  I-S/A  AMPE 
shall  also  provide  the  capability  (option)  to  send  modified  text  of  service 
messages  to  terminals  manned  by  non-communications  personnel.  This  option 
snail  be  selectable  on  a  terminal-by-terminal  basis  and  the  text  modification 
snail  be  such  that  the  service  message  is  easily  understandable  to  the 
non-communications  trained  personnel.  Additionally,  the  I-S/A  AMPE  shall  be 
designed  so  that  at  least  two  operator/service  positions  can  support 
processing  of  service  messages  if  the  primary  service  position  becomes 
overloaded . 

3.2. 1.6  Accountability  and  Recordkeepinq 


The  I-S/A  m.’vPE  shall  insure  that  messages  are  accounted  for  during 
processing  through  the  system  ana  shall  maintain  nistory  logs  ano  files  to 
record  this  accountability. 
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i.  «  Ci'^c5i  -C icue  I'.esss.jt  iCeiitiTTr::'  y^i  i)  snel]  oe  assicrico  to 
“^w"’  es3,.;ce  nCv-cptcu  Oj  tMc  i^r'iOti.ot'icn  i-b/.n  o'^c  ii.ciLiCc  posit',  e 

I  .-rnti  r  icatic!'.  ct  tne  origir.ati:  u  buDserioer's  purt  ana  tiie  oricinatinq  1-5,  A 
nr.PE.  Tins  lociicifier  shall  be  printea  on  all  pages  ot  the  ir.essage. 

b.  Mh  audit  trail  shall  be  maintaihea  within  each  I-S/A  AMPE, 
tracing  all  actions  perforfhec  on  the  message  as  a  whole.  (Ref  DcDC-5030. 5SM) 

c.  The  storage  of  message  anc  system  status  information  shall 
preclude  loss  of  stored  inrord,atiun. 


u.  Tne  system  shall  nave  tne  capaoility  to  annotate  on-line  .message 
riles  to  be  nonretnevao  le.  Uhen  the  system  or  an  operator  requests  retrieval 
of  tnat  message,  a  notir ication  shall  oe  sent  to  the  operator  position  stating 
tne  message  cannot  be  retrievec. 

e.  The  I-S/A  AImPE  shall  prevent  intermixing  of  portions  of  two  or 
more  messages.  The  I-S/A  aIvPE  shall  prevent  the  interlacing  of  messages 
Curing  processing.  See  oOD  C-5030.5SM,  page  23,  para  3f{5). 

3.2. 1.5. a  History  Logs  and  Files 

The  I-S/m  AI’iPE  shall  provice  for  storage  of  messages  ana  system  status 
information.  This  stored  information  is  used  to  recover  from  a  malfunction, 
to  support  retrievals  and  searches,  to  trace  tne  progress  of  messages  through 
the  I-S/A  mMPE,  and  to  support  the  statistics  function.  The  I-S/A  AMPE  shall 
provide  on  a  site  by  site  selectable  basis  the  storage  for  either  of  the 
:ol lowing; 


a.  All  messages  (including  service  messages,  but  excluding  the  text 
of  AUTODIN  Limited  Privacy  System  (ALPS)  messages)  processed  oy  the  I-S/A  AMPE. 

b.  All  narrative  messages  (including  service  messages,  but  excluding 
ALPS  messages)  as  well  as  the  text  of  selectee  data  pattern  messages. 

The  rttention  perioc  of  on-line  stored  messages  is  specified  in  3.5. 

3. 2. 1.6. 2.1  Incoming  anu  Outgoing  Uournul  Entries  -  System  Status 
Information 


The  I-S/A  AlfPE  snail  provide  tne  capability  to  store  and  access 
information  regarding  events  which  occur  curing  the  processing  of  a  message, 
as  well  as  information  whicn  describes  the  I-S/A  AMPE  configuration  ana  events 
which  cnange  the  configuration.  The  information  in  Tables  3.2. 1 .6.2. 1-1  and 
-2  shall  be  stored  for  each  message  or  system  event  as  appropriate.  The  I-S/A 
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Ta:::e  3.2. 1  .c  1-1  Lcurnal  Entries  -  '''essaces 


-tart  -t  "“Ssaae  input. 

Era  or  ressage  input  anc  input  cnannel  ana  CSi.  i:  apolicaole. 

3.  2t-.rt  or  ;::essauc  output. 

^Fi-.al:  Ere  or  -:essace  outcut. 

Ere  or  transinissicn  for  eacn  output  teriiiinal,  to  induce  ter-ainal 
iuentifier  anc  cnannel  nurtoer. 

6.  Ena  of  message  acknowlecgment  for  each  delivery  to  induce  CSi\  if 
applicable. 

7.  Lnique  F.essace  I  certifier. 

o.  Routing  incicator  ana  cnannel  number  of  eacn  cutput  message. 

9.  Error  summary  fer  each  message  to  induce  cate  ana  time  of  the 
message. 

IG.  Format  line  tnree  OSRI  (if  applicable). 

11.  Input  L.XF  pair  anc  actual  celivery  meaia  for  each  message. 

12.  Ifessage  status  table. 

13.  Retrieval  ana  retransmission  actions. 

14.  Security,  TCC,  TRC,  ana  SHD. 

15.  Message  lengtn  aata. 

16.  Statistical  data  (necessary  to  support  requirements  of  paragraph 
3.3.3). 

17.  Message  laenti fi cation  of  all  messages  scrubbed  by  the  system,  time 
and  reason. 

18.  Precedence. 

19.  Unsuccessful  attempts  by  a  subscrioer  to  input  message  traffic  to 
induae  date  and  time  of  each  occurrence  ano  reason. 

20.  Processing  time  in  system. 
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].  . '1  i  dt  Vw' .  il’iQ  Zcr"'li  il  c  L 1  Ol  >0  r  IP.piit  dliCi  Output  tC  OVct'fl^'.V  dnC  'illtcTCdpt 

st,^race . 

C'ji  r  i  ‘  ti  ,  tc  iocl-.cc  status  pcrip'iecajs  aiic  cnanncls, 
-j.rt.varc-  .■■_-'i~as5  ■; ,ti r  i c at'Oii  sr.c  sort.vare  patcocs  or  ‘'Otioris  iostallcc. 

3.  Channel  going  into/out  of  service. 

Sp'stem  state,  to  inciuce  failure  times,  restart  times. 


c,  recoro  or  all  input  from  anc  output  to  tne  system  operator  position  to 
induce  day  ana  tune. 


6.  rt  recoro  of  all  system  error  conuitions  or  abnormal  events  affecting 
message  traffic  processing  to  inciuce  oay  ana  time  of  eacn. 


7.  A  recoro  of  all  automatic  system  actions  taken  that  affect  message  traffic 
flow  or  overall  I-S/A  nMPE  operation  to  inciuce  day  ano  timfi  of  each 
action . 
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/■'•vi"PE  siial]  provioe  t!ie  sccrage  ana  access  f-^iKCicns  of  one  DoD  >',anua  i 
w-5C3C.cc:',  Ciiapter  3,  paragraph  5t^c). 

3 . 2 . 1 . 0 . 3  . ^  PcTer-iice  n.rir'ies 

Storec  inrorf"ation  on  each  message  ana  each  section  of  a  moltisectioneo 
message  snail  sopport  system  restart  ana  reloac,  statistics  requirements  (See 
3.3.3),  the  trace  of  all  actions  taken  on  eacn  'tessace  processeC,  ano  the 
searcn  or  ■Message  riles  fer  message  cata. 

3 . 2 . 1 . 0 . 3  riistcr:.  Sata  Interrogation 

The  I-S/A  AifPE  snail  provioe  the  system  operator  the  means  to  interrogate 
nistory  aata  (see  Taoles  3. 2. 1.6. 3-1  ano  3.2. 1 .6.3-2) .  Interrogation  criteria 
inclooed  in  Table  3.2. 1.6. 3-3  shall  oe  accommodated. 

3 . 2 .  1 .  7  .'fessace  Searcn,  Retrieval,  Reaocressal  ano  Retransmission 

all  files  and  logs  maintained  by  the  I-S/A  AikPE  snail  be  accessible  in 
Support  of  the  search  ana  retrieval  functions.  Search  is  the  process  of 
obtaining  message  oata  from  both  online  and  offline  files  in  order  to 
determine  wnich  messages  snoulo  be  retrieved.  Retrieval  is  the  process  of 
obtaining  tiessages  from  1-S/A  AMPE  online  ano  offline  storage  files. 

Retrieved  messages  are  then  processed  for  readaressal  and/or  retransmission. 
The  operator  shall  have  trie  capability  to  initiate  or  terminate  search, 
retrieval,  reaodressal  and  retransmission  operations 

3.2. 1.7.1  Message  Data  Search 

In  general,  the  I-S/A  AMPE  shall  support  searches  of  the  following  types 
and  combinations  of  tne  following  types: 

a.  Search  by  day  and  time. 

b.  Search  by  originating  station  routing  indicator  and  station 
serial  number. 

c.  Search  for  data  between  two  given  points  in  time,  defined  by 
Ordinal  date  and  time  of  day. 

d.  Searcn  by  unique  message  identifier. 

e.  Search  by  Channel  Sequence  f^umber  (CSN). 

r.  Search  by  precedence. 

g.  Searcn  by  classification. 

n.  Search  by  originator  ana  date-time-group  (DTG). 

Search  by  Destination  Routing  Indicator 
OSRI  and  SSl.  and  File  Time 
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I  I'.FOR.'  n  I  lO'i 


Start:  of  itiessace  input 

Era  or  Tussacc  iriput  acKriGwiacgei.;e''t 
inoU.oa  iir:\.:  onani^oi  anu  itiput 
if  applicaoic; 

Complete  copy  of  message  as  receiveo 
to  include  UMI 

Start  of  message  ouput  for  each  aooressee 
cn anne 1 

End  of  message  ac^nowlecgement  receiveo 
for  each  output  delivery  to  include 
CuSN  if  applicable 

Occurrence  of  each  cancellation  of  an 
output  transmission  to  include  reason 

Delivery  to  intercept  or  overflow  storage 

Receipt  from  intercept  or  overflow  storage 

(Final)  end  of  message  output 

Error  summary  for  each  message 

Recoro  of  retrieval  action  to  include 
output  delivery  data  for  each  message 

Unsuccessful  attempt  by  a  subscriber  to 
input  message  traffic  to  include  reason 
for  each  occurrence 

Input  and  output  message  length  for  each 
message  processed 

Information  concerning  message  retransmit- 
teo  and  recieved  from  an  error  correction 
dev i ce 


DCCL Ar ::i' uE  rNiLUr-vi,- 
YE5 

'/ES 

NO 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

NO 


YES 
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TdPle  3.2. 1.6. 3-2  System  Status  InTormation  to  be  S to rec 


INFORMATION 


uA i n  ANL  T 
OCCURRENCE 


System  Lonfi gurat ion  to  include 
status  of  peripnerals  and  channels 

YES 

Recoro  of  cnannel  going  into  or  out 
of  service 

YES 

Statistical  data  necessary  to  support 
the  requirements  of  3. 3.4. 2 

NO 

Message  queue  status 

YES 

Alternate  routing  status 

YES 

Overflow  and  intercept  file  status 

YES 

ocurnal  files  sufficient  to  support  the 
system  restart  and  reloao  requirements 
of  3. 3. 8. 2  ana  3. 3. 8. 4 

YES 

A  record  of  all  input  from  and  output 
to  the  system  operator  position 

YES 

A  record  of  all  system  error  conditions 
or  abnormal  events  affecting  message 
traffic  processing 

YES 

A  record  of  all  automatic  system  actions 
taken  that  affect  message  traffic  flow 
or  overall  AMPE  operation 

YES 

ME  OF 
RECORuED 
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Taoie  3.2. 1.6. 3-3  History  Data  Inforniat ion  Interrogation 


Interroqaticn  Criteria 


Average’^  Volu'-re  of  InforMticn’^ 

Access  Available  witnin 

TiiTie  Access  Time 


Tiir.e  of  Receipt  (TOR)  of  all  messages 
rtceiveu  on  a  given  cnannel 

TOR  of  all  messages  receivea  on  a 
given  cnannel  a  specific  OSRI, 
PLA,  or  LiSF 


TOR  of  all  messages  receivea  on  a 
given  channel  following  a 
specifiea  CSu,  OSRI/OSSfl  or 
plm/utg 


Time  of  Transmission  (TOT)  of  all 
messages  transmitteo  on  a  given 
channe 1 


TOT 


of  all  messages 
a  given  channel 
ae 1 i very  RI ,  ae 


transmitteo  on 
with  specifiea 
livery  PLA,  or  LMF 


TOT  of  all  messages  transmitted  on  a 
given  channel  (with  a  given  LMF  if 
applicable)  following  a  specified 
CSi\,  OSRI/OSSiN  or  PLA/DTG 


TOR  or  TOT  of  message  with  a  specified 
input  CDSN,  OSRI/OSSM,  PLA/DTG  or  UMI 

All  activity  (input  and  output)  on  a 

given  channel  between  specifiea  times 

All  system  restarts,  reloaas  or  error 
conditions  between  specified  times 


All  input  from  or  output  to  the  system 
operator  between  specified  times 


Information  on  messages  scrubbed  or 
rejected  by  tne  system  or  the 
operator  between  specified  times 


^(To  be  oetermineo) 


•^-RA 


Table  3. 2. 1.7. 1-1 

Searcnes  Provicea  oy  tne  I-S/a  AHPE  to  the  Operators 

1.  Searcn  ul  prints  all  s^'stem  restart  entries  and  all  monitor  printer 
printouts  tnat  are  on  the  historj/  riles. 

2.  Searcn  02  prints  li.essage  information  and  time  of  receipt  of  all  messages 
received  witn  a  particular  security  classification  or  preceoence. 

3.  Searcn  03  prints  message  information  for  all  m.essages  with  tne  specifieo 
Unique  Message  loentifiers. 

4.  Search  04  prints  message  heaoer  and  time  of  transmission  of  all  messages 
transmitted  to  a  given  channel. 

5.  Search  05  prints  message  heaoer  and  time  of  transmission  of  all  m.essages 
transmitted  on  a  given  oestination. 

6.  Search  06  prints  message  information  ana  time  of  receipt  of  all  messages 
witn  a  particular  security  classification  received  on  a  given  channel. 

7.  Search  u7  prints  message  icentif ication  of  all  messages  purged  by  the 
system  on  output. 

S.  Search  08  prints  all  message  information  that  has  been  stored  in  a 
specified  area  of  the  storage  media. 

9.  Search  09  prints  message  identification  of  all  messages  purged  by  the 
system  due  to  a  storage  failure. 

10.  Search  10  prints  message  information  and  time  of  receipt  of  all  messages 
received  with  a  given  originating  station  routing  indicator  after  a  giver 
time . 

11.  Search  11  prints  message  information  and  time  of  receipt  ana  time  of 
transmission  of  a  Mode  II,  Mode  I  optional  Transmission  Identifier  line 
users  by  channel  sequence  number  and  input  channel  number. 


12.  Search  12  prints  .message  heaoer  and  time  of  transmission  of  all  messages 
transmitted  to  a  given  Mode  II,  Mode  V  or  Mode  I  optional  Transmission 
Identifer  line  users,  following  a  given  channel  sequence  number. 

13.  Search  13  prints  message  identification  of  all  messages  received  with  a 
given  format  line  three  originating  station  routing  indicator  (OSRI) 
after  a  given  time. 

14.  Search  14  prints  message  header  and  time  of  transmission  of  all  messages 
transmitted  on  a  given  channel  to  a  given  destination. 

15.  Search  15  prints  message  information  and  time  of  receipt  of  all  messages 
received  on  a  given  input  channel,  following  a  specified  time. 


k.  ORSI  and  DTG 

l.  OSRI  ana  DTG  anc  Unique  Message  laentifier 

[fi .  PLrt  anc  U  I G 

n.  CSN  and  time  period 

0.  Content  Inaicator  Code 

p.  Delivery  Distribution  Indicator  (DOI) 

Each  search  nas  the  option  of  printing  all  the  message  information  or 
aobreviated,  journal  information  only.  The  I-S/A  AMPE  shall  perform  all 
searches  specified  in  Table  3. 2. 1.7.1  upon  operator  initiation.  Access  times 
are  specifiea  in  3. 5. 3. A.  ZULU  time  shall  be  usea  for  message  storage  ana 
retrieval  operations. 

3 . 2 . 1 . 7 . 2  Message  Retrieval 

Tne  I-S/A  AMPE  snail  support  the  retrieval  of  message  parameters  stored 
on-line  as  specified  in  3.2. 1.7.1.  Access  times  are  specified  in  3. 5. 3. 4. 

The  I-S/A  Al'iPE  system  or  its  operator  shall  be  able  to  request  message 
retrieval.  System  requests  shall  be  the  result  of  service  messages.  These 
service  requests  for  retrieval  may  be  made  only  by  the  originator  or  an 
aodrsssee  of  the  message  to  be  retrieved.  A  retrieval  request  from  a 
subscriber  shall  be  honored  only  if  the  subscriber  is  either  the  originator  or 
an  aaaressee  of  the  message  to  be  retrieveo  and  then  only  if  the  subscriber  is 
homea  to  that  I-S/A  AMPE. 

It  shall  be  possible  to  retrieve  up  to  10  messages  with  a  single  request. 
The  '.-S/A  AMPE  shall  allow  retrieval  of  messages  which  contain  two  sets  of 
originating  station  routing  indicators,  station  serial  numbers,  and  file  times 
oy  either  such  set. Channel  Designator  (CD),  Channel  Sequence  flumber,  or  unique 
Message  Identifier. 

3. 2. 1.7. 3  Message  Readdressal 

The  I-S/A  AMPE  shall  provide  a  message  reaodressal  function  defined  as 
those  actions  necessary  to  cause  a  message  to  have  a  new  set  of  aodresses 
assigned  which  differ  from  the  original  set.  Readoressal  shall  be  capable  of 
being  initiated  by  a  request  entered  (by  message  originator  or  original 
addressee)  at  the  service  position  or  by  use  of  a  DD  Form  173.  The  DO  173 
message  form  shall  be  accommodated  by  the  I-S/A  AMPE  for  the  preparation, 
release,  and  input  of  readdressal  requests.  The  form  will  be  identical  to 
that  for  a  message  origination  except  the  text  portion  shall  be  replaced  with 
tne  identification  of  the  message  to  be  readdressed.  Message  readdressal 
snail  also  be  accomplished  via  operator  entries  via  VDT.  Readdressals  shall 
be  accomplished  in  accordance  with  JANAP  128,  ACP  127  and  DOI  103. 

All  messages  for  which  new  addressees  are  so  inserteo  shall  be  routed  to 
tne  service  position  for  final  review  and  editing  of  the  header.  The  service 
position  shall  be  prohibited  from  editing  the  text  of  any  messages.  The 
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reaccressed  riessace  snail  snen  oe  routed  through  the  I-S/A  AMPE  as  if  it  .-.ere 
a  ne.v  "lessage,  .vUn  sec^ritv  cnec.<s,  internal  aistrioution,  and  corr.ebacN 
copies  inclucea  as  appropriate.  If  the  itessage  fails  to  pass  input  messace 
processing  ^sce  -.^.1.2^  the  reguestor  snail  be  notiried. 

3 . 2 . 1 . 7 .  A  f'essage  Retrans:rissicn 

Retransmission  is  the  resenoing  of  a  message  previously  transmitleo.  The 
I-S/n  rt.VPE  Shall  automatically  accomplisii  retransnii ss ion  v.hen  a  service 
message  requests  retrans>aissicn  ana  tne  following  conoitions  are  met: 

a.  The  retransmission  request  service  message  is  originateo  by  the 
originator  or  an  original  aaoressee  of  the  requesteo  message. 

b.  Tne  retransmission  request  is  for  10  or  less  messages. 

c.  The  service  message  ioentifies  the  messages  to  be  retransmitteo 
by:  tne  originating  station  routing  inoicator,  station  serial  number  ana  rile 
time;  cnannel  designator  and  channel  sequence  number;  Date  Time  Group;  or 
Jnique  Message  Identifier. 

a.  The  requestec  messages  are  contained  on  the  on-line  message 
storage  file. 


e.  The  requested  message  has  not  been  previously  retransmitteo  a 
certain  predefined  number  of  times,  set  by  the  I-S/A  AMPE  console  operator. 

The  retransmission  capability  shall  allow  the  I-S/A  AMPE  operator  to  perform 
retransmission  of  multiple  messages  cased  on  the  message  retrieval  capability 
of  FRD  3,2. 1,7.2, 

If  any  of  the  above  conditions  are  not  satisfied,  then  the  request  shall 
be  sent  to  the  I-S/A  AMPE  operator  for  resolution.  The  I-S/A  AMPE  operator 
shall  have  capability  to  override  cohditions  b  through  e.  The  requestor  shall 
oe  notified  if  the  retransmission  cannot  be  accompl isned.  Retransmission 
restrictions  are  specified  in  3, 2, 1,5, 8, 2,  All  retransmitted  messages  shall 
indicate  that  the  message  is  a  retransmission  in  accordance  with  the 
procedures  in  JAhAP  128,  ACP  127  or  DOI  103  as  appropriate, 

3, 2, 1,8  Automatic  Formatting,  Paging  and  Sectioning 

Tne  I-S/A  AMPE  shall  format  messages  to  include  paging  (assigning 
sequential  page  numbers)  ano  sectioning  (scanning  the  message  for  length  and 
appending  logical  segments  based  on  the  analysis)  of  originated  messages 
according  to  JANAP  128  and  DOI-103  for  each  user  requiring  such.  Each 
subscriber  shall  be  classmarked  at  initialization, 

3,2,2  Message  Editing  and  Preparation  Service  (MEPS) 

The  FMS  of  the  I-S/A  AMPE  shall  provide  automatic  assistance  to  operators 
in  the  process  of  message  entry.  This  capability  includes  automatic 


3-61 


I  II  ■■I'l  I . » I 


rr’ 


i 


« 


supervision  of  message  preparation,  message  mask  call-up  from  remote 
terminals,  and  eoiting  capao  i  1  i  t  ies .  ^'£PS  snail  be  available  to  all  users  .viio 
GO  not  deal  solely  in  fully  formatted  C,r\Un?  1£8,  AC?  127,  uOI-lu3  ana  301-103 
Special  messages.  For  terminal  suoscribers  tne  transactions  snail  be  in 
messages,  vice  cnaracters  or  lines.  For  local  terminals  (tnose  colocateo  witn 
tne  I-S/A  AMPE)  tne  editing  capability  shall  permit  the  suoscrioers  to  maKe 
corrections  ana  cnanges  to  his  message  both  curing  ana  after  entry  but  prior 
to  release.  Eciting  shall  include  insertion,  deletion,  ano  replacement  of 
cnaracter(s ) ,  woro(sj,  ana  line(s).  FiEPS  also  incluoes  conversion  rrom  OD  173 
message  form  to  OAAAP  123  ana  DOI  103  Tormat  ana  PLA  to  RI  assignment. 

3.2.2. 1  Automatic  Supervision  of  Message  Preparation 

Tne  I-S/A  AIvPE  shall  have  the  capability  to  automatically  guioe  the 
message  writer  through  the  process  of  entering  a  message  into  the  I-S/A  AMPE 
tnrough  tne  use  of  leading  questions  (e.g.,  format  desired,  security 
classification  desirea,  aocresses  aesirea,  examples  of  possible  responses, 
menus,  alternative  replies  ano  prompters,  community,  uSSCS  or  GENSER,  as  a 
mininium).  Diagnostic  messages  in  language  easily  uncerstooa  by 
noncomimunications  oriented  personnel  shall  be  sent  to  the  originators 
automatically  wnen  an  error  is  made  ouring  tne  entry  process. 

3. 2. 2. 2  Message  Preparation  MasKS 

A  mask  is  an  outlined  message  or  form  with  variable  fields  left  olanx  on 
the  VDT,  to  be  filleo  out  by  the  user.  The  I-S/A  AMPE  shall  provide  a 
stanoard  masN'  (00  173  form)  for  general  message  preparation,  a  CRITIC  mask, 
and  Certain  canned  formats  (operational  ano  oeployment  orders,  services 
messages  ana  en.ergency  action  messages)  for  specialized  usage.  The  I-S/A  AMPE 
snail  have  masxs  for  the  Standaro  Message  Form  (DO  173)  in  accordance  with 
ACP-121  and  the  CRITIC  masks  in  accordance  with  DOI-103.  The  I-S/A  AMPE  shall 
maxe  provision  for  18  other  masks  to  be  prescribed  by  the  users.  These  masks 
snail  be  able  to  be  entered  or  changed  by  the  local  I-S/A  AMPE  operator.  A 
page  of  a  preformatted  message  shall  be  displayed  on  the  screen  within  five 
seconds  of  the  user  request  for  the  message  mask,  when  a  mask  is  displayed, 
the  user  snail  have  the  capability  to  enter  variable  information  (some  fields 
will  have  default  values,  for  routine  precedence,  while  others  must  have  valio 
data,  e.g,,  from/to  info.),  create  and  edit  text  material,  and  release  the 
message.  Controls  snail  be  exercised  to  restrict  a  private  library  of  masks 
from  being  received  by  the  general  community  (i.e.,  masks  for  CRITIC  messages 
would  only  be  permitted  at  designated  1-S/A  AMPEs). 

3. 2. 2. 3  Message  Editing  and  Review 

The  I-S/A  AMPE  subscriber  shall  be  able  to  edit  messages  during  entry  and 
after  entry  but  prior  to  release  by  inserting,  deleting,  and/or  replacing 
characters,  words  ana/or  lines. 


k7 


3. 2. 2. 3.1  Line  tditina 


Tnrouch  editing,  the  message  writer  shall  nave  the  capability  to  insert 
new  lines,  delete  existing  lines,  or  replace  any  specirieo  line  with  a  ntw 
line  tnen  entcreo. 

3. 2. 2. 3. 2  Character  and  '.-joro  Euitinc 

The  I-S/n  Ai-iPE  editing  capabilities  shall  allow  character  or  word 
deletions,  replacen.ents  ano  insertions  in  a  line  tnat  nas  been  identified  fcr 
editing,  or  in  the  last  line  just  entered  if  editing  is  being  ccne  during 
message  entry. 

3. 2. 2. 3. 3  Copy  Review 

Tne  I-S/A  AMPE  shall  provide  a  review  copy  of  the  message  in  either  a 
narocopy  format,  or  as  an  editeo  display  at  tne  VDT.  With  the  display 
feature,  tne  I-S/A  Al-iPE  shall  nave  tne  capapility  to  scroll  the  message  either 
forward  or  bacxward  to  aio  the  proofreader. 
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3. 2. 2. 4  Format 

Tne  MEPS  sha 

ii 

ready  for  transm 

JrtNrtP  128  format 

for  DSSCS  users, 

properly  organiz 

classif icaticn. 
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to  RI  assignment 
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to  RI  Assi cnment 


n  perform  actions  requirea  to  transform  messages  not 
ission  ^e.g.,  messages  reaa  from  DC  Form  173/3)  to  either 
tea  messages  for  GEASEK  users  or  001  103  formatteo  fnessaces 
suitaole  for  transmission  via  the  FMS.  In  adaition  to 
inu  the  message,  FMS  shall  ensure  that  preceoence  LriF, 

CIC,  OSRI,  OSS't,  TOF,  security  sentinel,  reaundant 

start  of  routing,  RI(s)  and  the  eiiC  of  routing,  as  v.el  1  as  all 

ormai  lines  are  properly  included.  This  shall  reouire  a  PLA 


3.2.3  Service  Manageiiient 

At  IOC  the  I-S/A  AMPE  shall  provide  management  of  FMS  with  its  MEPS, 
conrol  of  subscriber  connections  and  the  VCS  connection  to  the  DDh.  The  I-S/A 
AMPE  snail  provioe  the  variety  of  subscribers  termination  modes  listed  in 
paragraph  4. 2. 2. 2  of  the  ICO.  At  IOC  the  I-S/A  AMPE  shall  provide  and  manage 
the  following  sunset  of  tne  Data  Flow  Paths  of  paragraph  3. 1.5. 3.1: 

0  Local  terminal  subscriber  to  local  FMS  ( 3. 1 . 5. 3. 1 . 1 ) . 

0  Local  Fi'iS  to  distant  FMS  via  the  DDh  (3. 1 .5.3. 1 .4) . 

3.2.3. 1  Terminal  to  FMS  Connection 

The  I-S/M  AMPE  shall  provide  fixed  connection  depending  on  prestored 
classmarks  for  each  terminal  either  to  FMS  directly  or  to  FMS  via  MEPS.  The 
direct  FMS  connection  is  to  be  used  by  terminals  transmitting  Modified  ACP 
126,  ACP  127,  JAhAP  128,  Navy's  Abbreviated  SI,  DOI  103  or  DOI  103  Special 
fully  formatted  messages.  The  MEPS  connection  is  to  be  used  by  terminals 


transmitting  OD  173,  NSA's  Abbreviated  SI,  or  other  less  than 


traffic.  Note 
require  PLA  to 


the  Modified  ACP 
RI  assignment,  a 


126  ano  Navy's 
MEPS  function. 


Abbreciated  SI 


ful ly  formatted 
formats  both 


3. 2. 3. 2  Local  FMS  to  Distant  FMS 


At  IOC  the  I-S/A  AMPE  shall  provide  and  manage  a  VCS  capability  to 
interconnect  the  FMS  modules  of  the  various  I-S/A  AMPEs.  Note  that  the  I-S/A 
AMPE  is  to  be  a  host  user  of  the  DON.  In  addition  to  the  VCS  protocols  TCP 
and  IP  (see  ICO,  4.2.4  and  4.2.5)  a  new  protocol  FMP  (ICO  4. 2.6. 2)  is  required 
which  is  the  interfacing  protocol  between  the  routines  of  FMS  and  those  of  TCP. 

3. 2. 3. 3  Management  Flexibility 

The  I-S/A  AMPE  design  shall  accomodate  a  robust  Service  Management 
Function  controlling  all  the  3. 1.5. 3. 3.1  data  flow  paths  ano  multiple 
services,  see  P^i,  paragraph  3.12. 
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3 . 3  System  Control 

3.3.1  System  Control  Concept 

Wit.hin  the  DCS,  system  control  is  the  function  whereby  communications 
assets  are  used  to  maintain  and  restore  maximum  system  performance  under 
changing  traffic  conditions,  natural  or  manmade  stresses,  disturbances,  and 
equip.ment  disruptions.  Basic  aspects  of  system  control  include  (1)  timely 
acquisition  of  system  performance  data,  facility  and  traffic  load  status,  an 
service  quality  indications;  (2)  rapid  analysis,  processing,  and  display  of 
information;  (3)  decision-making  and  control  execution;  and  (4)  support  of 
longer  range  system  management  and  engineering. 

The  Integrated  AUTODIN  System  (IAS) ,  as  a  subsystem  of  the  DCS  is  requir 
to  include  control  functions  as  part  of  its  design  and  implementation.  That 
design  and  implementation  must  also  consider  the  interaction  of  the  IAS  with 
other  DCS  elements. 

The  I-S/A  AMPES  and  the  DDN  are  sub-elements  of  the  IAS.  The  I-S/A  AMPE 
can  be  viewed  as  a  number  of  subscriber  hosts,  each  with  multiple  terminals, 
interconnected  via  a  backbone  packet  switched  network  (DDN).  The  DDN  consis 
of  approximately  175  Packet  Switching  Nodes  (PSNs).  Each  PSN  will  be 
programmed  to  examine  itself  and  its  environment  periodically  and  to  report 
the  results  of  these  examinations  to  a  processor  designated  as  the  System 
Monitoring  Center  (SMC),  also  referred  to  as  a  BLACK  Monitoring  Center.  The 
term  Monitoring  Center  (MC)  will  be  used  to  refer  to  that  functional  portion 
of  the  control  process  responsible  for  the  I-S/A  AMPE  subnetwork. 

Each  host  subscriber  to  the  DDN  will  operate  at  its  own  specified  system 
high  security  level  (the  design  allows  for  subnetworks  consisting  only  of  a 
specific  compartment).  Separation  of  each  subnetwork  is  provided  by  the  use 
of  End-to-End  Encryption  (E^) .  There  will,  therefore,  be  at  least  one  E^ 
cryptographic  key  for  each  different  subnetwork.  The  e3 ,  in  effect, 
prevents  anyone  not  included  in  the  subnetwork  from  communicating  with  the 
host  behind  the  E^  device,  including  the  SMC.  This  security  separation 
protection  leads  to  the  requirement  for  separate  l-S/A  AMPE  MC  functions. 
These  MC  functions  may  be  viewed,  like  the  SMC,  as  a  processor  attached  via 
host  interface  to  a  PSN,  however,  final  design  may  dictate  another  approach. 
The  MC,  supporting  the  I-S/A  AMPE  subnetwork,  will  be  behind  an  e3  device 
with  appropriate  key  variable(s).  This  will  allow  the  MC  function  to 
communicate  with  each  I-S/A  AMPE.  The  concept  for  control  of  the  I-S/A  AMPE 
subnetwork  can  be  summarized  as  follows; 

Each  I-S/A  AMPE  will  be  responsible  for  monitoring  itself  and  its  environmer 
(including  its  associated  terminals)  and  periodically  reporting  the  results 
the  .MC  function.  Each  I-S/A  AMPE  will  also  broadcast  certain  control  and 
status  messages  to  the''  DCA  Operations  Center  (DCAOC)  and  all  other  I-S/A  AMI 
in  the  subnet'work  to  advise  them  of  various  traffic  controls  such  as 
temporarily  inhibiting  other  I-S/A  AMPEs  from  transmitting  low  precedence 
traffic  to  it.  In  effect,  two  levels  of  network  control  will  exist,  both 
under  the  overall  control  of  the  DCAOC.  One  level  within  the  backbone  is  tl 
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responsibility  of  the  DDN.  The  second  level  is  within  the  I-S/A  AMPE 
subnetwork  and  will  be  the  subject  of  discussion  in  the  reraainder  of  this 
section. 

It  is  important  to  note  that  the  terms  SMC  and  MC  refer  to  the  hardware  and 
software  type  functions  to  be  used  in  an  integrated  control  process  that 
supports  the  overall  system  control  function  of  the  IAS.  Although  the  SMC  ar 
MC  functions/ccmputers  are  important  components  of  the  network,  their 
operation  must  not  be  essential  to  either  the  DDN  backbone  or  to  the  I-S/.A 
AMPE  subnetwork. 

3  .  3 . 1 . 1  S/stem  Control  Evolution 

The  I-S/A  AMPEs  in  conjunction  with  the  DDN  will  provide  the  capability  t 
phase  out  the  AUTODIN  Switching  Centers  (ASCs)  currently  serving  Formal 
Message  Service  (FMS)  subscribers.  Initially,  the  I-S/A  AMPE  will  connect  tc 
both  ASCs  and  pSNs.  During  ^-his  initial  stage,  the  present  AUTCDIN  control 
centers  will  be  responsible  for  the  total  combined  ASC  and  I-S/A  AMPE 
subnetwork,  with  the  I-S/A  AJ-IPE  MC  pro'.  Lding  necessary  monitoring  and  control 
functions  for  the  I-S/A  AMPE  subnet'wor!' .  As  subscribers  are  rehomed  to  I-S/; 
AMPEs  and  the  l-S/A  AMPEs  are  interconnected  via  DDN,  the  ASCs  will  be  phasec 
out.  During  all  phases  of  the  transition,  coordination  and  cooperation  with 
the  DDN  SMC  will  be  required. 

3. 3.1.2  Connectivity  Requirement  for  System  control 

Each  I-S/A  AMPE  will  use  DDN  service  for  its  primary  system  control 
communications.  In  addition,  the  system  control  design  will  allow  for  the  us 
of  dial  up  service  for  backup  system  control  communications  to  send  and 
receive  system  control  data  and  directives.  All  system  control  data 
transmissions  will  be  encrypted  and  have  authentication  policies  and 
safeguards  to  prevent  malicious  or  accidental  modifications.  Further,  I-S/A 
AMpE  operators  will  be  provided  with  dial  up  voice  service. 

3.3.2  Subnetwork  Management  and  Control 

Monitoring  Center  functional  interfaces  will  be  extended  to  the 
geographically  separated  AUTODIN  Control  and  Operations  centers  (ACOC) .  In 
this  way,  network  management  and  control  will  be  supported  by  the  Monitoring 
Center  function.  Control  and  operations  centers  in  the  CONUS  will  be  backed 
up  by  subordinate  regional  monitoring  centers  located  in  the  pacific  and 
Europe. 


3 . 3 . 2 . 1  Integrated  AUTODIN  System  Control  process 

The  Integrated  AUTODIN  System  control  process  will  utilize  elements  for 
the  AUTODiN,  DDN,  and  I-S/A  AMPE;  and  will  include  the  hardware,  software, 
personnel  and  procedures  necessary  to  perform  the  assigned  functions.  The 
I-S/A  AMPE  MC  functions  which  will  take  control  inputs  from  each  l-S/A  A.MPE 
and  coTipile,  store,  and  present  information.  The  information  will  be  used  £ 
developing  responses  to  routing  problems,  unanticipated  subnetwork  problems, 
long-term  planning  for  network  configuration  management,  and  billing. 
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3. 3. 2. 1.1  Crisis  Manaaenient 


A  major  function  of  trie  MC  will  oe  to  support  the  management  of  crises  or 
contingency  conoitions.  This  ..ill  be  accurrpl  isneo  oy  provioing  the  f.C 
function  associated  with  the  I-S/A  Mi-iPEs  the  capaoility  to  selectively  apply 
control  measures  before  the  subnetworK  capability  is  unacceptaoly  ciegraceo. 
However,  as  discussed  earlier,  the  ability  must  be  provided  to  continue 
expeditious  networN  control  uncer  wartime  conditions,  witnout  an  operational 
MC.  The  I-S/m  aMPE  operator,  or  the  hC,  will  be  able  to  provioe  destination 
code  cancellation,  or  to  block  access  by  selected  users  or  precedence  levels. 
Adequate  authentication  and  verification  procedures  must  be  provided  to 
preclude  citner  inadvertent  or  malicious  disruptions  to  the  operation  of  the 
subnetworK . 

3. 3. 2. 1.2  Network  Modification  Control 

Tne  I-S/A  AMPE  operator  will  review  network  modification  control  changes 
prior  to  implementation  in  order  to  ensure  that  improper  changes  cannot  be 
made  as  a  result  of  accidental  access,  deliberate  attempt,  or  communications 
failure.  (Tne  MC  will  be  capable  of  directing  and  controlling  the 
implementation  of  I-S/A  AMPE  software  changes  and  routing  table  updates. 

These  changes  will  be  transmitteo  to  the  I-S/A  AMPE  via  secure  means  and 
subject  to  a  verification  process.) 

3.3.3  Configuration  Monitoring  ana  Control 

Configuration  monitoring  and  control  is  concerned  with  maintaining  current 
records  of  the  network  access  ana  connectivity  to  the  backbone.  Each  I-S/A 
AMPE  shall  maintain  status  information  on  its  connected  user  locations  and 
transmission  links,  and  temporary  records  of  reroutes  ana  subsequent  restorals 
up  to  the  point  of  connection  to  tne  backbone.  The  MC  function  will  maintain 
records  of  all  connectea  users  and  their  locations,  servicing  I-S/A  AMPE,  and 
user  characteristics.  The  I-S/A  AMPE  shall  automatically  (as  an  operator 
selectable  option)  transmit  to  the  ACOC  ana  DCAOC  changes  of  this  information. 

3.3.3. 1  Activations/Deactivations  of  Subscribers  and  Transmission  Links 

The  I-S/A  AMPE  operator  shall  be  provided  the  capabilities  to  coordinate 
ana  implement  the  activation  and  deactivation  of  subscribers  and  supporting 
transmission  links.  In  aaaition,  each  I-S/A  AMPE  operator  shall  be  provided 
the  capability  to  review  and  either  accept  or  reject  updates  in  routing.  In 
the  event  the  MC  function  is  disabled  the  I-S/A  AMPE  shall  have  the  capability 
to  broadcast  the  update  information  to  all  other  I-S/A  AMPEs. 

3. 3. 3. 2  Subscriber  ana  DON  Access  Line  Reroute  and  Restoral 


Each  I-S/A  AMPE  shall  support  the  reroute  and  restoral  of  failed 
subscriber  lines,  ASC  access  lines,  ana  the  I-S/A  AMPE's  DON  access  lines. 

This  capability  shall  be  provioed  as  part  of  the  I-S/A  AMPE's  Fault  Isolation 
and  Correction  (FI&C)  function.  (See  Section  3.3.6)  All  circuit  reroutes  and 
suDsequent  restorals  shall  be  monitored  ana  automatically  reported  to  the  MC. 
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3. 3. 3. 3  i^etworK  Configuration  Engineering 

The  conf i9L:rati on  engineering  fiinction  of  tne  I-S/A  AMPE  subnetwork  will 
use  tne  latest  networK  cent iguration  anc  resource  availaoilitj  cata  together 
with  nistorical  information  concerning  line,  trunk  and  equipment  utilization 
ana  performance  monitoring  measurements  to  plan  ana  maximize  the  I-S/A  AMPE 
sub-network  performance.  This  information  will  reside  in  the  HC  to  be  usea 
for  configuration  engineering  purposes.  The  I-S/A  AMPE  role  in  performance  of 
this  function  snail  be  to  automatically  provide  the  informatio,.  required  by 
tne  MC,  ana  to  respond  to  airectives  or  requests  for  adaitional  oata  as 
specified  in  Section  3.3.4. 

3.3.4  Traffic  Flow  ano  Routing  Control 

The  DDN  backbone  proviaes  for  flow  control,  and  dynamic  routing  to  hosts 
(I-S/A  AMPE)  connected  to  the  backbone.  The  I-S/A  AMPE  (and  associated  MC) 
shall  provide  traffic  flow  and  routing  control  for  indivioual  I-S/A  AMPEs  and 
their  terminal  elements.  The  I-S/A  mMPE  shall  be  capaole  of  supporting  these 
control  capabilities,  and  the  MC  will  have  the  capability  to  previoe 
airectives  to  the  I-S/A  aMPE. 

3.3.4. 1  Traffic  Flow  Control 


The  I-S/A  AMPE  shall  provide  flow  control  mechanisms,  specified  below,  to 
permit  the  I-S/A  AMPE  operator  to  alleviate  problems  associated  with  traffic 
congestion  at  individual  I-S/A  AMPEs.  Congestion  can  result  from  failed 
hardware  or  software  m.oaules,  error  prone  transmission  cnannels,  insufficient 
storage  resources,  or  unusual  surges  in  incoming  message  traffic.  Flow 
control  shall  be  implemented  without  denying  subscribers  access  to  the  Formal 
Message  Service.  Tne  I-S/A  AMPE  shall  provide  the  following  controls; 

a.  A  traffic  intercept  control  to  direct  messages  --  up  through 
Immediate  --  to  a  mass  storage  device  upon  direction  from  the  I-S/A  AMPE 
operator.  Once  implemented,  traffic  intercept  shall  remain  in  effect  until 
cancelled  by  the  operator.  The  effect  of  intercept  is  to  temporarily  remove 
traffic  from  the  I-S/A  AMPE.  Intercept  would  normally  be  employed  in  the 
event  of  a  subscriber  line  outage  or  high  traffic  volumes  destined  for 
subscribers . 


b.  An  automatic  dial-up  capability  to  obtain  a  temporary  path  to  a 
terminal,  an  ASC,  or  another  I-S/A  AMPE  shall  be  provided.  This  has  the 
effect  of  enhancing  network  availability  and  will  be  used  in  the  event  of  a 
circuit  failure  or  for  relief  of  high  volume  to  a  specific  circuit.  This 
control  shall  be  under  operator  control.  Automated  dial-up  capability  shall 
be  provided  such  that  no  operator  involvement  is  required  beyond  initiation, 
or  approval,  of  the  dial-up.  Any  dial-up  connection  so  obtained  shall  be  the 
operational  equivalent  of  a  permanent  connection. 

c.  The  capability  to  automatically  generate  reports  of  congestion, 
intercept  status,  ana  queue  status  and  transmit  these  reports  to  the  MC  shall 
oe  provided. 
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0.  Tne  capability  to  issue  ana  respona  to  I-S/A  AMPE  congestion 
control  coRiiianas  to  terr.por ari  ly  innibit  other  I-S/A  AMPEs  from  attempting  to 
transRiit  lower  tnan  FLaSH  prececence  traffic  to  the  I-S/A  AMPE.  The 
congestion  control  ccnmands  shall  be  automatically  implementeo.  For  control 
in  crises  eacn  I-S/A  AMPE  snail  automatically  commana  otner  I-S/A  AKPEs  to 
cease  sending  traffic  to  user  terminals  connecteo  to  the  commanding  I-S/A  AF'.PE 
which  have  terminated  operations.  The  I-S/A  AiNPE  operator  shall  have  the 
capability  to  override  these  commands  and  shall  have  tiie  capability  to 
implement  the  control. 

3. 5. 4. 2  Routing  Control 

The  I-S/A  AMPS  shall  provide  routing  control  capabilities  to  respond  to 
line  and  subscriber  outages  or  relocation  of  a  suoscriber.  The  I-S/A  AMPE 
■vhich  implements  a  routing  control  snail  notify  the  MC  of  the  action. 

Prevision  shall  be  maae  to  permit  all  appropriate  routing  tables  or  oata  bases 
at  PSAs  and  otner  I-S/A  AMPEs  to  be  notified  by  an  operator  of  routing 
controls,  without  the  aid  of  tne  MC.  Different  types  of  routing  actions  shall 
oe  provided  and  the  control  shall  induce  as  a  minimum: 

a.  A  control  to  automatically,  or  upon  operator  cemand,  route 
messages  to  predefined  alternate  addresses  (terminals).  This  control  shall  be 
implemented  automatically  in  the  event  of  a  subscriber  line  or  terminal 
failure  or  serious  impairment.  The  capablility  shall  be  provided  to  permit 
the  operator  to  specify  (as  the  paranieters  which  initiate  the  automatic 
control):  (1)  A  degree  of  circuit  impairment,  and;  (2)  A  time  period 
(operator  selectable  from  zero  to  30  minutes j  during  whicn  this  impairment 
exists.  In  addition,  the  I-S/A  AMPE  snail  be  capaole  of  storing  an  alternate 
address  for  eacn  subscriber. 

b.  A  subscriber  line  routing  control  to  transfer  messages  to  the 
alternate  path  of  oual-homed  subscribers  upon  operator  command.  This  control 
would  be  employed  in  tne  event  of  subscriber  line  failure.  The  primary 
serving  I-S/A  AMPE  shall  send  the  routing  change  to  the  MC. 

c.  An  alternate  routing  control  in  the  event  of  a  destination  I-S/A 
AMPE  or  user  failure/relocation.  In  the  case  of  failure  of  a  destination 
I-S/A  AMPE  or  user,  the  source  I-S/A  AMPE  shall  be  capable  of  utilizing 
"prestored"  routing  table  updates.  These  tables  shall  be  capable  of  being 
electrically  transmitted  utilizing  the  MC  function.  Such  transmission  will  be 
encrypted  and  will  have  authentication  policies  and  safeguards  to  prevent 
malicious  or  accidental  modifications  of  routing  tables.  Each  I-S/A  AMPE 
shall,  upon  operator  command,  be  capable  of  redirecting  all  traffic  originally 
destined  to  the  failed  I-S/A  AMPE  or  user  to  a  specified  alternative. 

3.3.5  Status  Monitoring  anc  Performance  Assessment 

Status  monitoring  and  performance  assessment  provides  data  on  the  I-S/A 
AMPE,  subscribers,  transmission  media,  and  network  to  determine  the  status  of 
the  system  as  it  is  currently  operating  and  the  performance  over  an  extended 
period  of  time. 
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3. 3. 5.1  Status  Monitorincj 


Tne  I-S/m  AMPE  subtietwor<  is  composec!  of  individual  facilities  v/here 
io.pt'oper  operation  i::aj  cause  network  disruptions.  Ifnproper  operation  results 
in  two  categories:  inipairea  operation,  in  which  the  suo-network  or  element  is 
capaole  of  operation  but  not  within  its  rated  operational  parameters;  and  an 
outage,  in  which  the  sub-networK  or  element  is  not  operable.  Status 
monitoring  is  intendeo  to  oetect  such  conditions  arid,  in  addition,  provide 
ir.foniiation  on  the  operational  status  of  reounoant  equipment.  Change  of 
status  events  snail  be  reported  irroeoi ately  to  the  I-S/A  mMPE  operator.  The 
capability  snail  oe  prcvioed  to  nave  these  reports  automatically  forwarded  to 
tne  HC. 

3.3.5. 1.1  I-S/A  AMPE  Status  Monitoring 

3. 3. 5. 1.1.1  Impairment/Outage  Conoition 

The  status  monitoring  function  shall  provioe  the  capability  to  ioentify 
wnen  tne  I-S/A  nHPE  is  in  an  impaired  or  outage  conoition.  I-S/A  AI-iPE  status 
shall  be  considered  to  be  impaireo  when  the  I-S/A  Ai-'.PE  fails  to  serve  all 
connected  subscribers,  is  not  capable  of  maintaining  its  rateo  tnrougnput,  or 
cannot  provide  all  services.  The  impairment  monitoring  ano  reporting  shall  be 
oaseo  on  a  setable  tnresholo,  adjustable  over  the  range  from  70  to  ICO 
percent.  The  I-S/A  AMPE  shall  be  in  an  outage  conoition  when  it  cannot  pass 
traffic. 


3. 3. 5. 1.1. 2  Equipment  Status 


The  status  monitoring  function  shall  provide  the  capability  to  identify 
outages  in  I-S/A  AMPE  equipments.  Examples  of  typical  equipment  items  for 
which  status  is  requireo  are:  Processing  Units,  Memory,  Disk,  Console,  I/O 
Devices,  and  Scanners. 

3. 3. 5. 1.1. 3  Hazardous  Condition 

Tne  status  monitoring  function  shall  provioe  the  capability  to  identify 
hazardous  operating  conditions.  A  hazardous  operating  conoition  exists  when 
an  I-S/A  AMPE  equipment  failure  occurs  and  any  further  failure  of  this  type  of 
equipment  will  result  in  I-S/A  AMPE  failure  or  impairment. 

3. 3. 5. 1.2  Subscriber  ano  DDN  Access  Line  Impairment  ana  Outage 

The  status  monitoring  function  shall  provioe  the  capability  to  detect  when 
subscriber  and  access  lines  are  in  an  impaireo  or  outage  conoition.  A 
subscriber  or  access  line  is  defineo  as  the  transmission  meoia  ano  all  line 
naroware  associated  with  it,  (e.g.,  cryptographic  equipment  ano  mooems).  A 
subscriber  or  access  line  shall  be  considered  impaired  when  it  fails  to 
operate  at  rated  speed  ano/or  rateo  error  rate.  The  subscriber  or  access  line 
is  considered  out  of  service  when  it  is  incapable  of  passing  any  traffic. 


3. 3. 5. 1.3  EquipiTient  Status 


Tne  status  inonitoring  functicn  snail  provice  the  capability  for  the  I-S/A 
n.'-.PE  to  icentify  outages  in  the  subscriber  ano  access  line  equipitent. 

Exar;ples  or  typical  equipment  items  tor  which  status  is  requireo  are: 
cryptograpiiic  equipment  ana  niocems. 

3. 3. 5. 1.4  Subnetwork  Status 

The  XC  will  continuously  monitor  subnet.vor^  status  from  a  combination  of 
operator  ana  automatically  generatec  reports  rrom  the  I-S/A  AXPE  operator  to 
the  MC.  Tne  suo-network  status  reports  will  incluae  I-S/A  Al-lPE  ana  subscriber 
outage  or  impairment  status,  congestion  reports,  trarric  alternate  routes  in 
effect  ana  aetectea  sub-networK  error  conuitions. 

3. 3. 5. 2  Performance  Assessnient 

The  I-S/A  AMPE  shall  provide  a  capability  to  assess  its  performance  ana 
tnat  of  all  cunnectea  lines.  The  I-S/A  AXPE  shall  ce  capable  of  reporting 
substanaard  performance  characteristics  to  tne  local  operator  and  to  the  XC. 
This  snail  oe  accomplished  in  real  time  on  an  exception  basis,  i.e.  when 
thresholds  are  exceeoea.  The  thresholds  shall  be  setable  for  each  channel  ana 
parameter.  Upon  request  from  the  operator  cr  the  N.C,  inaiviaual  parameters  or 
preaeterminea  groups  of  parameters,  shall  be  reported. 

3. 3. 5. 3  Traffic  Header  Statistics 

The  I-S/A  AMPE  shall  be  capable  cf  providing  a  complete  record  of  traffic 
activity  from  its  history  records.  This  capability  shall  not  interfere  w'itn 
the  throughput  capability  or  tne  on-line  I-S/A  AMPE.  This  capability  shall  be 
available  to  produce,  within  a  two  oay  time  period  from  request,  an  extract  of 
any  24  hour  period  of  history  files.  This  capability  shall  not  have  a 
significant  impact  upon  the  workload  of  the  I-S/A  AMPE  personnel  (i.e., 
require  no  more  than  five  minutes  of  any  one  hour  period  dedicated  to 
accomplishing  this  task).  The  traffic  statistics  to  be  extracted  snail  be 
modeled  after  the  ASCs  Header  Extract  Program,  the  contents  of  whicn  are  shown 
on  Table  3.3. 5.3.  This  extracted  information  shall  oe  transmittea  to  the  MC 
for  further  processing. 

3. 3. 5. 3.1  Traffic  Statistics  Processing 

A  traffic  statistical  program  package  shall  be  developed  and  contain  all 
the  applicable  data  presently  contained  in  the  DCS  Switch  Profile,  Record 
Communications  Report  (see  Section  40.0).  These  programs  will  be  run  on  the 
processors  at  the  MC.  The  traffic  statistical  package  will,  in  addition  to 
the  above,  satisfy  the  requirements  outlined  in  3. 3. 5. 3. 1.1  through  3. 3. 5. 3. 3. 

3. 3. 5. 3. 1.1  Total  Traffic  Volume 


Data  on  subscriber  access  lines  are  received  and  transmitted  in  units  of 
messages,  line  blocks,  or  cnaracters.  This  data  shall  be  listed  and  shall 
include  the  total  number  of  incoming  and  outgoing  data  units  for  each 
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suDSCriber  line  by  R  or  Y  community  ana  for  DDN  access  line(s).  OD/N  access 
line  units  shall  be  packets  and  the  total  number  of  bits  transmicteo  ana 
receivea.  The  statistical  program  package  shall  recoru  the  numoer  of  messages 
anc  lineblocks  tnat  are  received  and  transniittea  over  a  specif iea  time  perioa, 
broKen  out  by  cnannel,  classif ication,  preceaence,  language  ana  meaia  format, 
format  or  media  conversions,  PLA/RI/LA  conversion  or  any  comoination  of  these 
breakouts . 

3. 3. 5. 3. 1.2  Susy  Period  Traffic  Volume 

Tne  statistical  program  package  shall  aeterinine  each  I-S/A  AT'PE's  busy 
hour  based  on  tne  traffic  sent  ana  receivea  by  its  subscribers.  It  shall 
induce  the  peak  volumes  for  eacn  trunk  and  subscriber  access  line  ana  busy 
hour  total  for  each  aestination  I-S/A  AMPE.  Totals  shall  induce  traffic  on 
queue  for  output  delivery  and  on  intercept  and  overflow  storage  as  appropriate. 

3. 3. 5. 3. 1.3  Multiple  Aaaressinq  Factor 

The  average  multiple  adaressing  factor  for  any  predefined  message  category 
or  comoination  of  categories  (defined  in  Section  3. 3. 5. 3. 1.1)  shall  be 
computed  for  each  I-S/A  AMPE  or  group  of  I-S/A  AMPE's  for  any  time  period 
specified  up  to  24  hours. 

3. 3. 5. 3. 2  Speed  of  Service  Data 

Speed  of  service  (SOS)  data  shall  be  computed  for  each  message  delivery 
and  included  in  a  report  tor  each  precedence  level.  SOS  is  aefined  as  the 
time  at  which  a  message  starts  into  a  I-S/A  AMPE  until  the  time  of  delivery  at 
tne  destination  I-S/A  AMPE.  The  time  frame  covered  by  the  report  shall  be 
specified  by  the  operator.  The  mean  SOS  shall  be  reportea  for  each  I-S/A  AMPE 
pair  by  precedence.  The  messages  that  nad  the  maximum  SOS  ana  the  minimum  SOS 
shall  be  listed.  The  Header  Extract  Records  for  these  messages  shall  also  be 
reportea . 

3. 3. 5. 3. 2.1  Network  Delay 

The  MC  is  to  report  the  same  data  for  Network  Delay  that  is  reportea  for 
SOS.  Network  Delay  is  defined  as  the  elapsed  time  between  an  EOM  received  at 
an  I-S/A  AMPE  until  the  message  is  queuea  for  output  at  the  destination  I-S/A 
AMPE. 

3. 3. 5. 3. 2. 2  SOS  &  Network  Delay  Matrix 

The  MC  will  report  for  any  specified  time  period,  up  to  24  hours,  both  the 
mean  SOS  and  the  mean  Network  Delay  experienced  between  each  I-S/A  AMPE  pair 
by  preceaence. 


3. 3. 5. 3. 3  Message  Lenqth 


The  average  message  length,  by  precedence,  of  all  Formal  Message  Service 
(FMS)  traffic  during  the  24  hour  sample  shall  be  determined. 
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Table  3-.3.5.3.  Header  Extract  Record  Format 


CHARACTER 

POSITION 

DESCRI ption 

NORMAL  CONTENTS 

1 

Message  precedence 

Y,w  =  [  Y  =  Emergency  Command  Precedence 

[  W  =  CRITIC  ] 

2  =  Flash 

0  =  Operational  immediate 
P  =  Priority 
R  =  Routine 


2 

Input  Language  Media 

Teletype  =  A,  F,  G,  Q,  R,  or  T 

Format 

Data  Pattern  =  C  or  S 

Mag  Tape  =  B,  D,  or  I 

3 

Output  Language  Media 
Format 

Same  as  character  position  2 

4 

Message  Security 

M  =  Special 

T  =  Top  Secret 

S  =  Secret 

C  =  confidential 

R  =  Restricted 

E  =  EFTO 

U  =  Unclassified 

5 

Originating  Switch 
Designator 

ASC  Entry  Switch 

6 

Blank 

— 

7 

Input  channel  Type 

8-14 

Originating  Station 
Routing  Indicator 

See  AMIE  Tributary  Listing 

15-18 

Originating  Station 
Serial  Number 

Numeric  value,  zeros  for  test  messages 

19-21 

Message  Length 

Length  in  line  blocks 

22-28 

Time  of  File 

Ordinal  date  and  time  received  from 
or ig ina  tor 

29-35 

Time  of  Transmission 

Date  and  time  of  entry  into  AUTODIN 

36-42 

Start  of  Message  In 

43-47 

End  of  Message  in 

These  fields  give  start  and  stop  times 
of  message  processing 

48-54 

Start  of  Message  Out 

55-59 

End  of  Message  Out 

fable  3. 3. 5. 3.  Header  Extract  Record  Format  for  ASCs 


CHARACTER 


POSITION 

DESCRIPTION 

60-61 

Routing  Indicator 
Count 

61-68 

Destination  Routing 
Indicator 

69-71 

Input  Channel  Number 

72-74 

Destination  Number 

75 

Reporting  Switch 
Designa  tor 

76-78 

Output  Channel  Number 

79 

Output  Channel  Type 

80 

Content  Indicator 

NORMAL  CONTENTS 

If  more  than  one  destination  is  pro¬ 
cessed  by  a  single  transaction,  there 
is  one  record  for  each  destination 
and  this  field  is  numbered 
consecutively  from  01  to  n. 

See  AMIE  Tributary  Listing 

Numeric  or  codes,  SVM,  ICI  or  IMI 

ASCs  code  for  destination 

Designator  for  switch  making  the 
transaction . 

Numeric,  ICO,  or  IMO 


Type  of  transaction 
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3 . 3 . 5 . 3 . 4  NS/ A  AMPE  Loao  and  T nrougiiput  Data 

Loac  aaia  shall  be  gatnerea  on  a  regular  and  as  requirea  basis  (regular 
inierval  to  oe  estaolisiiec  bj^  operator  console  con'iriandj.  Occurrences  ct 
cstdD  I  i  sued  tnresnolas  oeing  exceeded  shall  be  forwaraea  to  tne  i-iC.  The 
purpose  or  tnis  data  is  to  pruviae  real-time  statistics  on  the  utilization  of 
the  I-S/A  Ai-iPii  resources  ana  to  surface  throughput  proolems  as  tney  occur. 

Tnis  data  shall  be  reportea  to  the  operator  ano  the  MC.  The  peax  lb  second 
period  in  eacn  hour,  amount  of  traffic  througnput  in  sacli  hour,  anc  tne 
average  tnrcugnput  per  nour,  shall  be  reported  wnen  requestea  by  ti.e  MC. 

3 . 3 . 5 . 3 . 5  access  Line  SacKlog  Data 

Access  line  backlog  thresholas  shall  be  adjustable  and  shall  be  determined 
based  on  an  analysis  of  network  performances  ana  operational  proceoures.  When 
the  traffic  threshold  for  a  line  is  exceeded,  tne  operator  shall  receive 
notification  messages  which  incluae  number  of  messages,  volume,  ana  time  of 
occurrence.  This  data  shall  oe  accessible  to  the  operator  by  line, 
precedence,  and  Language  Meaia  Format  (LMF). 

3.3.6  Reporting 

3 . 3 . 6 . 1  OCAC  310-55-1  Reporting 

The  I-S/A  AMPE  is  to  be  designated  as  a  DCS  Reporting  Station  as  defined 
in  OCAC  310-55-1,  Status  Reporting  for  the  Defense  Communications  System.  In 
this  capacity,  the  I-S/A  AMPE  subnetwork,  equipment,  trunk  and  subscriber 
outages  shall  be  reportea  to  DCA  in  accordance  with  DCAC  310-55-1.  Tins 
reporting  by  the  I-S/A  APiPE  shall  be  automated.  Report  preparation  shall  be 
computer  assisted  to  minimize  operator  worxload  and  participation  in  all  but 
the  decision  making  process. 

3. 3. 6. 2  MC  Reporting 

Tne  I-S/A  APiPE  snail  transfer  performance  assessment  and  status  data  to 
the  MC  for  system  control,  billing,  and  planning  purposes.  This  data  shall  be 
reported  real  time,  at  operator  specified  periods  and  on  request  depending  on 
the  nature  of  the  data.  For  example,  real-time  reporting  would  be  associatea 
with  threshold  violations.  Periodic  reports  would  be  the  transfer  of 
statistical  aata  at  regular  time  intervals,  depending  on  the  collection  method 
ana  information  requirements.  On  request  reporting  shall  be  proviaed  to 
accommodate  MC  special  requests  for  additional  information  or  transfer  of 
statistical  data  on  a  real-time  rather  than  a  periodic  basis  for  purposes  of 
operational  direction  and  control  under  crisis  conditions.  The  I-S/A  AMPE 
shall  notify  the  MC  of  changes  in  status  of  the  access  lines  and  I-S/A  AMPE 
major  equipments. 

3. 3. 6. 3  Subscriber  Reporting 

The  I-S/A  AMPE  snail  be  responsible  for  reporting  subscriber  status  to  the 
MC.  Subscriber  utilization  data  shall  be  collected  continuously  and  forwarded 
by  statistical  report  message  daily  to  the  MC.  The  data,  based  on  all  message 
deliveries  for  each 


3-76 


raaio  day  (.'^aaay)  ano  sorted  by  Originating  Station  Routing  Inoicator  vOSRI), 
sliall  inci'^ce:  reporting  I-S/A  AMPE,  originating  I-S/A  AI-iPE,  total  nuinoer  of 
;nessages,  total  nuii.oer  or  lineblocks,  total  nuitber  of  high  precedence 
messages,  total  nun.ber  of  hign  precedence  lineblocks.  •■'ultiple  deliveries  of 
tne  same  i.’.essage  shall  be  counted  once  for  each  oe livery. 

Subscribers  will  provioe  reports  to  the  connected  I-S/A  AMPE  on  outages 
and  changes  in  equipment  status  which  affect  the  transmission  of  message 
traffic  to  or  from  tne  I-S/n  AMPE.  The  I-S/m  mMPE  shall  forward  these  recorts 
to  tile  I'iC . 

3. 3. 6. 4  DCS  v'.essaqe  Quality  Control  Data 

The  I-S/A  AMPE  shall  record  and  report  statistics  on  messages  rejectee  for 
specified  reason  cooes  and  other  data  necessary  to  implement  the  DCS  Message 
Quality  Control  Program  as  prescribed  by  ACP  121  US  Supp-1.  It  shall  also  be 
responsicle  for  generating  Communication  Improvement  Memoranda  (CIMs)  to 
subscrioers  for  rejected  messages. 

3.3.7  Fault  Isolation  and  Correction  \FI&Cj 

An  integral  part  of  each  I-S/A  AMPE  racility  shall  pe  a  FI&C  Capability 
l,FICC)  to  monitor,  test,  ano  substitute  circuits  or  equipments  connected  to 
the  I-S/A  A^.PE.  The  FICC  shall  include: 

a.  A  circuit  configuration  data  base  containing  the  circuit 
identification  number  ano  identifying  tne  various  components  comprising  the 
circuit. 


b.  Circuit  quality  monitor  and  alarm  indication  of  circuit 
oegraoation  or  outage. 

c.  Rapid,  remote  access  to  circuit  segments  for  loopback  ano 

testing . 

d.  Automatic  fault  isolation  using  loopback,  remote  test  equipment 
and  software  routines. 

e.  Semi -automated  switching  for  replacing  defective  equipment  or 

circui ts . 

The  goal  of  the  FICC  is  to  create  an  environment  which  will  maximize 
circuit  and  access  trunk  reliability,  quality  ano  speeo  of  restoration  while 
minimizing  personnel  requirements.  The  I-S/A  AMPE  FICC  function  shall  provide 
both  automated  and  manual  operations  on  all  circuits  connected  to  the  I-S/A 
AMPE.  All  security  requirements  shall  be  maintained  during  these  operations. 
The  operator  will  be  provided  4-wire  AUTOVON  access  ano  other  switched  voice 
networks  as  appropriate  to  establish  coordination  with  other  I-S/A  AMPEs, 

PSNs,  ASCs,  'Jbscribers,  and  the  MC  as  required. 


3.3.7. 1  Circuit  Configuration  Data  Base 

The  circuit  configuration  data  base  shall  be  accessible  from  the  I-S/A 


nr, PE  operaior  console  ana  shall  cepict  tne  terminal  to  I-S/A  AhPE  circuit 
confi guraticn  incluoing  icenti r ication  or;  the  subscrioer,  critical 
parameters,  eacn  niajor  equipniei.t  item  in  the  circuit,  and  test  points  or 
laopoac'K  points  in  tne  circuit.  The  purpose  or  the  circuit  cenf igurati on  cata 
odse  is  to  ^JroviGe  a  re^ay  reference  for  the  operator  in  performing  fault 
isolation  ana  in  oirecting  repair  activities.  Spare  assets  shall  also  be 
oescribec  in  the  oata  base. 

j . j . 7 . d  Circuit  Cualit<  rionitor 

Eacn  circuit  snail  oe  provicec  with  both  local  ana  remote  monitoring 
capaoility  to  aetect  aorcrmal  conaitions  anu  equipment  alarms.  Each 
malfunction  shall  be  oisplayeo  at  the  operator  console  ana  snail  iaentify  the 
conaition  by  circuit  numoer.  Greater  cetail  regarding  the  status  of  the 
equipment  in  the  malfunctioning  circuit  shall  be  displayed  upon  request  by  the 
operator. 

3 . 3 . 7 . 3  Remote  Access  to  Circuit  Segments 

Remote  access  to  circuit  segments  shall  be  provided  either  through 
inherent  capaoilities  of  the  circuit  elements  (cryptographic  equipment, 
modems,  terminals,  etc.)  or  via  auxiliary  comiponents  under  control  of  the 
operator.  This  access  shall  provide  for  loopbacks  ana  the  connection  of 
requisite  test  equipm.ent. 

3 . 3 . 7 . 4  Automatic  Fault  Isolation 

Upon  receipt  of  a  fault  indication  on  a  circuit,  the  operator  shall  be 
able  to  activate  automatic  fault  isolation  routines  which  initiate  a  series  of 
loopbacKS  toward  the  I-S/A  AMPE,  and,  in  conjunction  with  remotely  controlled 
test  equipment,  isolate  the  circuit  segment  or  equipment  causing  the 
malfunction. 

3. 3. 7. 5  Semi -Automated  Switching 

Each  I-S/M  AMPE  facility  shall  oe  provided  with  semi-automatic  switching 
which  will  allow  rapid  restoration  of  service  once  a  fault  is  located.  Upon 
command  from  the  console  operator,  spare  equipment  or  circuits  can  be  put 
on-line  to  replace  the  faulty  element.  All  operational  circuits  shall  be 
accessible  and  permit  switching,  monitoring  ana  testing.  In  particular,  the 
semi-automated  switching  shall  support: 

a.  Channel  swapping  (Rea  or  Black/ 

b.  Equipment  swaps  (modem,  crypt;,,  timing  source) 

c.  Circuit  testing  (new  suDsenoer  acceptance) 

d.  Spare  channel  capaoility 

(1)  Between  the  I-S/A  AMPE  and  the  serving  Primary  Technical 
Control  Facility  (if  applicaole) 
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(2)  For  software  testing 


e.  phase  III  rehome  capability  (DCA  OPLAN  1-79) 

f.  AUTOVON  and  Public  Telephone  and  Telegraph  (PTT)  dial-up  and 
res  tor al  capability 

g.  Subscriber  community  separation. 

3. 3. 7. 5.1  Red/Black  Isolation 

The  requirements  of  MlL-HDBK-232  and  of  DoD  manual  C-5030.58M,  Chapter  3, 
paragraph  3b(6),  shall  be  met  for  Red/Black  isolation. 

3. 3. 7. 5. 2  Subscriber  Community  Separation 

Provision  shall  be  made  to  provide  appropriate  separation  of  subscriber 
comjnunities .  For  example: 

a.  Red  Patch  Frame:  GENSER  U.S.  and  Allied  subscribers  with  the 
capability  to  preclude  inadvertent  cross  connection  of  U.S.  and  Allied 
channels . 


b.  Yellow  Patch  Frame:  DSSCS  subscribers  only  with  the  capability 
to  preclude  inadvertent  cross  connection  of  selected  compar tmented  DSSCS 
subscr ibers. 


c.  Red  and  Yellow  Frame  Separation:  No  cross  connection  capability. 

3. 3.7. 6  Interface  with  Technical  Control 

The  I-S/A  AMPE  will  be  provided  an  interface  with  appropriate  elements  of 
the  DCS  serving  Technical  Control  where  applicable.  This  interface  shall  be 
used  by  the  I-S/A  AMPE  to  monitor  fault  alarms,  threshold  violations,  and 
circuit,  trunk  and  communications  equipment  failures  and  HAZCONs  that  may 
affect  the  I-S/A  AMPE  connectivity  to  the  ASC,  PSN,  or  subscribers. 

3.3.8  Billing  Data 

The  I-S/A  AiMPE  shall  maintain  data  to  support  both  billing  by  connection 
and  billing  by  utilization.  (The  Government  will  select  one  or  the  other 
scheme.  Even  if  not  selected  for  billing  purposes,  utilization  data  will  have 
engineering  and  management  value.) 

3.3.9  I-S/A  AMPE  Internal  Con tr ol 
3 . 3 . 9 . 1  Operator  Control  Function 

The  operator  control  functions  provide  the  I-S/A  AMPE  with  all  operational 
services  and  man-machine  interfaces.  The  I-S/A  AMPE  console  operator  control 
functions  shall  provide  for  the  following: 

a.  control  of  programs,  1)  system  start-up,  and  2)  system  loading 
procedur  es . 
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b.  Display,  print,  and/or  modify  data  base  entries. 

c.  Control  network  operating  parameters  such  as  message  routing, 
traffic  thresholds,  time-out  values  and  reroute  plans. 

d.  Display  and  recording  of  l-S/A  A-MPE  performance,  status 
condition  alarms,  and  switchover  to  backup  facilities. 

e.  Placi.ng  units  on  or  off-line  and  forcing  change-over  to 
redundant  units. 

f.  Monitoring  status  of  the  I-S/A  AMPE,  backbone  access  line(s), 
subscriber  lines,  and  initiating  required  action  in  response  to  status  changes 
including: 

(1)  Channel  out  of  service  both  send  and  receive  immediately. 

(2)  Channel  out  of  service  either  send  or  receive  immediately. 


transmiss  ion. 


message . 


(3)  Channel  out  of  service  receive  following  receipt  of  current 


(4)  Channel  out  of  service  receive  following  receipt  of  current 


(5)  Channel  in  service  send,  receive  or  both. 

(6)  Display  and  set  input  and  output  Channel  Sequence  Numbers 


(CSNs)  . 


(7)  Generate  by  command  a  cancel  (CAN)  or  reject  message  (RM) 
control  on  any  connected  channel. 

g.  Display  of  current  FICC  connection  configuration. 

h.  Control  of  local  test  initiation. 


frcm  the  MC. 


Report  generation  in  response  to  local  requests  and  requests 


Display  of  current  traffic  controls. 


k.  coordination  with  other  IAS  Network  Elements. 

3. 3. 9. 2  Failure  Recovery  Management 

Failure  recovery  management  is  the  ability  of  the  I-S/A  AMPE  to  perform 
recovery  from  a  system  outage  and  includes  initialization,  reload,  restart, 
and  reconstruction  of  system  files  to  a  secure  state.  Initialization 
capability  shall  be  provided  which  will  establish  all  control  measures  for  the 
correct  operation  of  the  equipment.  The  l-S/A  AMPE  shall  maintain  a  backup 
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for  Z’.\e  reconscruccion  of  svsteir  files.  For  restart  or  reloao  ttie  I-S/m  AfiPE 
shall  securel>  provioe  for  relcao  of  the  system  generation  software  and 
applications  prograics,  inclL.v.ing  the  caca  oase  or  riles,  to  enaole  a  restart 
of  railed  egaipiiienr  or  coirplere  startup.  Security  attriDutes  are  prescrioeo 
in  Section  3.-. 

3. 3. y. 2.1  Autcmatic  Recovery 

Trie  I-S/e,  rtlfPE  snail  have  a  secure  gracerul  oegraaation  of  services  and/or 
speed  as  failures  occ.>r,  .vith  autoiratic  transfer  of  critical  functions  to 
reserve  orocessor  capaoilicy.  Ir  the  on-line  system  sustains  a  failure  all 
appropriate  peripneral  devices  and  communications  terminating  equipment  snail 
Pe  automatically  switcheo  to  remaining  processor  capability.  All  security 
requirements  shall  be  maintained  during  the  above  procedures.  The  I-S/A  AriPE 
shall  maintain  in  non-volatile  memory  the  information  describing  the 
configuration  data  to  securely  support  system  restart  and  reload,  to  maintain 
performance  statistics,  ano  tc  support  message  tracing  actions.  The  I-S/m 
AmPE  shall  be  capaole  of  reloaoing  and  performing  an  on-line  recovery  of 
undelivereo  traffic  automatical ly .  Notification  of  software  failures, 
hardware  rai lures,  ano  peripneral  oevices  failures  shall  be  automatically 
oirected  to  the  I-S/A  AMPE  operator  or  to  the  MC,  or  ooth.  Security 
requirements  are  further  defined  in  Section  3.4. 


3. 3. 9. 2. 2  iVanual  Recovery 

The  capability  for  similar  actions  to  those  specified  in  3. 3. 8. 2.1  shall 
oe  availaole  with  human  intervention.  Typical  processes  requiring  manual 
intervention  are: 

a.  Enter  bootstrap  loader  program. 

b.  Enter  system  software  from  an  external  storage  medium. 

c.  Enter  applications  programs. 

d.  Update  all  files  with  data  from  last  checkpoint. 

3. 3. 9. 3  Data  Base  Management 

Data  base  management  includes  maintaining,  updating  and  displaying  the 
data  base.  Examples  of  data  bases  include  routing  taoles,  security  tables, 
procedure  lists,  subscriber  or  user  classmarks,  connectivity  and  configuration 
data,  historical  logs,  ahd  status  data.  The  I-S/A  AMPE  shall  provide  the 
capability  to  securely  process  data  base  updates  upon  receipt  from  the  MC, 
other  I-S/A  AMPEs  and  the  local  system  control  operator.  A  capaoility  shall 
be  provided  to  maintain  data  base  integrity.  Initiated  data  base  changes 
Shall  be  mace  frem  clearly  unoerscood  input. 

Data  base  changes  shall  be  subjected  tc  cross  reference  and  validation 
before  being  mace. 

Data  oase  information  snail  be  accessible  oy  the  operator  in  readily 
understood  ana  useful  format(s).  It  shall  be  possible  to  provide  an 
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ir.aividuai  I-S/A  AMPE  the  capability  to  securely  restrict  data  base  changes  to 
either  on-line  or  off-line  changes.  New  information  entered  at  the  MC  shall 
be  distributed  and  incorporated  throughout  the  network  to  all  affected  I-S/A 
AMPEs.  In  addition,  update  information  entered  at  a  particular  I-S/A 
AMPE  shall  be  capable  of  being  broadcast  to  all  other  l-S^A  AMPEs  when  the  MC 
is  disabled  or  disconnected.  The  I-S/A  AMPE  operator  shall  be  notified  of  all 
data  base  updates  prior  to  local  implementation. 

The  I-S/A  AMPE  shall  have  the  data  base  and  reports  generation 
capabilities  presented  in  Section  50.0. 


T  / 


l-S/A  Ai-.PE  Security 


►  . 

r*.-  • 


j.-.i  General 


Tnis  section  estaolishes  tne  security  cesign  criteria  for  tne  I-S/A  A'.P£ 
nara.vdre  ana  sottware.  The  goal  of  tne  I-S/A  Hi*iPE  is  to  tie  la  a  system  tnat 
.vill  be  accreoitea  for  the  consol iaateo  handling  of  Defense  Special  Security 
Ccmiiiunicatiors  System  (^SSCS)  ana  General  Service  (GEh'SER)  message  traffic  nc.-/ 
processea  tnr'cugn  rtUTOuIh. 

The  messages  and  oata  processec  by  the  I-S/m  AmPE  will  oe  of  varying 
security  levels  ana  security  compartments.  Thus  the  I-S/A  AI'iPE  must  oe 
certifiea  as  Multilevel  Secure  (MLS).  In  order  to  meet  tliis  certification, 
the  I/S-A  AMPE  hardware  ana  software  snail  meet  the  criteria  specifieo  nere. 

As  a  minimum,  the  I-S/A  AMPE  shall  induce  a  trustee  computing  base  (TCB) 
capaole  of  Class  "Al"  certification  (See  Section  30)  consisting  of  the 
following  capaoi 1 ities: 

A  secure  operating  system  ana  an  appropriate  access  control  mechanism 
certifieo  for  use  in  an  MLS  environment  that  provices  requisite 
protection  from; 

unauthorizeo  disclosure, 
unautnorizea  denial  of  service,  ana 
unauthorized  alteratioh. 

.  Hardware  isolation  mechanisms  complementary  to  the  secure  operating 
system  and  provioing  the  requisite  security  necessary  to  meet  the 
criteria  specified  in  this  section. 

3.4.2  DSSCS/GEHSER  Integration 

At  IOC  the  I-S/A  AMPE  will  be  fielded  as  two  deployments,  one  a  GENSER 
only  aeployment  for  the  "R"  community  ana  secona,  a  OSSCS  oeployment  for  the 
"Y"  ano  "R/Y"  community.  [.Note  that  "R/Y"  terminals  are  in  fact  "Y"  terminals 
allcwea  to  pass  "R"  traffic  in  aoaition  to  their  normal  "Y"  traffic.]  It  is 
intenPed  that  these  be  two  deployments  of  a  single  I-S/A  AMPE  development.  On 
the  network  side  of  the  I-S/A  AMPE  tne  ASC  will  proviae  "R"  and  "Y"  separation 
until  transition  to  the  DON,  at  which  time  the  Blacker  Program  technology  will 
be  used  to  maintain  the  "R"  ana  "Y"  separation.  Each  deployment  of  the  I-S/A 
mMPE  shall  be  multilevel  secure.  The  I-S/A  AMPE  will  be  subjected  to 
extensive  design  proofs  and  testing  as  part  of  the  certification  and 
accreditation  process.  Tne  Director,  DCA  is  the  GENSER  accreditation 
authority.  JIA  and  NSA  liave  the  accreditation  responsibility  for  Special 
Intelligence  (SI)  handling  and  JCS  for  Single  Integrated  Operations  Plan 
(SIOP)  handling.  Preceding  the  accreditation  of  the  system,  NSA  will  make 
recommendations  to  the  accreoiting  authorities  based  on  NSA's  analysis  and 
verification  of  tne  I-S/A  AMPE  system  security. 

3.4.3  Security  Certification 

Tne  I/S-A  AMPE  shall  meet  the  criteria  of  Class  Al  as  describee  in  Section 
30.  Class  Al  requires  that  formal  methods  be  employed  to  verity  the  design  of 
the  trusted  computing  base.  For  details  see  Section  30. 
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It  is  not  r.anGatory  that  the  I/S-A  rt.VPE  meet  the  criteria  cf  Class  A2  as 
tnis  class  is  Currently  consiaercQ  beyono  the  state-of-the-art.  Huivever, 
aspects  of  Class  m2  tnat  can  ce  accomp 1 ishec  snoula  be  considerea  for 
incorporation  into  tne  I-S/n  mMFE.  [note:  To  r.eet  Class  A2,  a  Tormal 
analysis  of  the  ooject  coae  is  reqoireo  to  prove  that  tne  iirplen.entation 
software  fulfills  tne  requirement  of  the  security  mocel.  also,  formal  methocs 
of  verification  are  appliea  to  tiie  narav.are  design.] 

3.^. A  Crvptcqrapnic  Security 

The  I-S/A  AifPE  will  intertace  with  the  lihN  encryption  equipment  currently 
fielced  ano  in  use  in  the  DCS  tor  suoscrioer  terminals;  this  induces  the 
KG-13,  KVj-7,  KG-34,  KW-26,  and  KG-S4  systems.  The  I-S/A  AMPE  shall  also 
interface  with  the  end-to-eno  encryption  (E^)  equipment  being  developed  for 
NSA  under  the  BLACKER  program. 


3 . 5  Ptrr O'^-nariC-^  •\equiren:ents 

All  "c^'rcr "ui.oe  requi re'retits  or  cne  I-S/A  AKPE  spcciriea  nerein  snoll  be 
S3i;is’’'ie-  s ^  k  _;iec'js  ly  jnless  speeiricaily  cxei'.pted. 

3.5.1  ^rarfic  Prccessing 

Tde  I-S,'A  ni'r'E  shall  process  ttie  traffic,  witn  those  characteristics  and 
trafric  lOdO  spccirieo  in  paragrapn  o.o.l.l.  The  total  crafric  load  is 
specified  in  pa''ugrapn  3.5. 1.3.  Tne  maxiruir.  alki-.cole  delay  tor  processing  an 
inaiviuual  iressage  or  data  transaction  throogn  tne  I-S/A  ANPE  is  specified  in 
paragrapn  3.5. l.L  The  derivation  of  the  expected  I-S/A  AMPE  input  traffic 
from  connected  terminals  is  detailed  in  Table  3.5.1.  Total  traffic  is  derived 
in  F 1 gure  b( a) . 

3.D.I.I.  Formal  Message  Service  Traffic  Characteristics  and  Traffic  Loads 

The  input  from  Formal  Message  Service  traffic  tne  I-S/A  AMPE  shall  be  able 
to  process  on  a  sustained  basis  is  12.2  KBPS  (19.0  line  blocks  per  second). 

Tne  lengtn  of  messages  is  expecteu  to  be  negative  -  exponentially  distributed 
with  a  mean  length  or  2075  characters,  (2b  line  blocks)  (the  maximum  length  of 
a  message  is  4-, QUO  cnaracters).  Therefore  tne  I-S/A  AMPE  shall  be  expected 
to  process  .73  input  messages  per  second  on  the  average.  Twenty-five  percent 
of  input  messages  are  expected  to  be  multiple  addressed;  and  given  that  it  is 
a  multiple  addressed  message  the  expedted  average  of  the  number  of  audressees 
per  message  is  4.2.  The  expected  message  distribution  by  precedence  is: 


Flash  and  above 

ko 

Immedi ate 

12% 

Priority 

38% 

Routine 

49% 

The  expected  expansion  factor  for  local  delivery  and  distribution  is  5  (for 
each  message  having  at  least  one  local  addressee,  the  message  must  be 
delivered  to  5  local  channels).  The  resultant  output  from  Formal  Message 
Service  the  I-S/A  AMPE  shall  process  on  a  sustained  basis  is  50  KBPS  (77  line 
blocks  per  second)  which  is  expected  to  equate  to  3  output  messages  per  second 

3.5. 1.1.1  Input  Traffic  Processing  Capability 

The  I-S/A  AMPE  shall  process  input  traffic  at  the  sustained  rate  of  at 
least  12.2  KBPS  (19.0  line  blocks)  per  second  with  a  total  connected  input 
line  load  of  192,000  bits  per  second.  After  operating  at  the  sustained  input 
and  output  rates  for  30  minutes  processing  the  expected  load  with  full  input 
and  output  line  capabilities,  the  I-S/A  AMPE  shall  be  capable  of  handling  the 
rollowing  surge  conditions  witnout  denying  input  of  Formal  Message  Service 
traffic  at  its  sustained  input  rate  of  12.2  KBPS  (19.0  line  blocks  per  second) 
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a.  LOSS  of  all  output  availability  for  ten  (10)  niinutes. 

b.  Surge  of  input  load  to  192,000  bits  per  second  for  20  seconds, 
output  line  capability  not  impaired.  All  input  data  in  this  20  seconds  shall 
be  processed  and  not  lost. 

After  either  surge  condition  the  I-S/A  A-MPE  shall  be  able  to  recover  to 
the  presurge  conditions  within  one  hour  while  continuing  to  process  data  at 
the  normal  soecified  sustained  rate. 


Tnerefore  it  is  expected  that  tne  average  connected  terminal  population  will 
generate  7.25  lineDlocks  per  second  of  traffic  to  the  serving  I-S/A  AMPE. 
This  figure  is  used  as  Ix,  the  expected  terminal  input  load  in  Figure  6(a). 
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3. 5. 1.1. 2  Qjtput  Traffic  Processing  Capability 

The  l-S/A  AiMPE  shall  process  and  output  traffic  at  the  sustained  cate  of 
at  least  50,000  data  bits  per  second  (77  line  blocks  per  second)  with  a  total 
connected  output  line  capacity  of  192,000  bits  per  second.  Reduction  of 
output  line  capability  shall  not  impact  on  the  I-S,'A  AMPE  capability  to 
process  traffic  and  queue  it  for  output  at  the  above  sustained  rate  (See  3.5.3 
Storage  Requirements).  If  traffic  has  queued  up  for  all  output  lines  for  any 
reason  and  all  output  lines  become  available  to  accept  traffic  at  their 
maximum  rate,  then  the  I-S/A  AMPE  shall  be  able  to  output  traffic  at  the  rate 
of  the  sum  of  the  output  line  capabilities  up  to  a  rate  of  at  least  200,000 
bits  per  second  while  still  processing  new  data  for  output  at  the  sustained 
rate  of  at  least  50,000  data  bits  per  second  (77  line  blocks  per  second). 

3. 5. 1.2  Throughput  Traffic  Processing  Capability 
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Throughput  is  defined  as  the  sum  of  input  plus  output.  The  I-S/A  AMPE 
shall  throughput  traffic  at  the  sustained  rate  of  at  least  61,500  data  bits 
per  second  (96  line  blocks  per  second) . 

3. 5. 1.3  Traffic  processing  Delays 

Traffic  processing  Delay  is  defined  as  the  elapsed  time  from  time  of 
receipt  of  the  last  element  of  an  incoming  message  by  the  I-S/A  AMPE  until  the 
message  is  processed  and  transmission  is  initiated  for  output  on  all 
applicable  output  lines.  The  transmission  time  into  or  out  of  the  I-S/A  AMPE 
is  not  considered  part  of  the  processing  delay  time.  The  individual  traffic 
elements  shall  be  processed  within  the  time  delays  specified  in  the  following 
subparagraphs  while  processing  the  total  sustained  input  and  output  traffic 
loads  specified  in  3. 5. 1.1  above. 

3. 5. 1.3.1  Formal  Message  Service  processing  Delays 

The  processing  delay  for  formal  messages  is  defined  as  the  elapsed  time 
from  the  receipt  of  the  end-of-message  sentinel  on  input  of  a  message  until 
all  required  copies  of  the  message  are  queued  for  output  and  transmission  of 
the  first  data  bit  (if  the  output  lines  are  available  and  not  queued  up). 

This  includes  all  message  format  and  heading  validation,  PLA  to  Rl  conversion, 
Rl  to  logical  address  conversion  as  required,  routing  segregation, 
distribution  and  delivery  determination,  placement  in  all  output  queues, 
establishment  of  internal  I-S/A  AMPE  connections  where  required,  and  start  of 
transmission  of  all  copies  of  the  message  (on  output  lines  that  are  available 
and  not  queued  up  with  equal  or  higher  precedence  traffic) .  The  allowable 
traffic  delays  are  specified  for  each  precedence  as  follows:  the  maximum 
value  of  the  mean  processing  time  E(t)  and  the  elapsed  time  at  which  the 
probability  of  completion  shall  be  0.95,  Prob  (t^T  =  0.95). 
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PRECEjENCE 

ciL-P  ii 
F  lasn 
Innieci  ate 
Priori  tv 
Routine 


MEA,'J  PROCESSING 
TIKE  E;t) 

0.75  ScC 
1  Sec 
5  Sec 
30  Sec 
cO  Sec 


PROb  (t=TJ=0.y5 
T 


1.25  Sec 
1.7  Sec 
S  Sec 
50  Sec 
135  Sec 


Tne  1-5,  A  r,!-.PE  snail  teet  or  tetter  tre  aocve  processing  celays  .-.hile 
processirc  tne  sjstainec  loao  or  3.5. l.L,  anc  iv.nile  processing  a  . -ssage  .-.itn 
tne  follo.ving  cnaracteristics : 


Message  length  5,400  characters 

Two  aocressees  -  One  remote  (terminateo  on  another  I-S/A  AMPE)  ana 
One  local  (oirectly  terminatec ) 

Local  oelivery  cistrioution  expai.sion  of  4  (i.e.,  to  be  output  on  4 
local  cnannels;. 

2.5. 1.3.2  Data  Transactions  to  tne  IAS  Network 


Post  100  nen-FMS  traffic  shall  ce  exchangeo  with  the  IAS  Network  as  oata 
transactions.  A  oata  transaction  snail  consist  of  tne  receiving  of  a  block  of 
data  from  a  local  terminal  and  tne  conversion  of  the  clock  of  data  to  paCKets 
and  tne  transmission  of  the  packets  through  the  PSN  backbone.  The  receiving 
of  a  group  of  packets,  comoining  into  a  block  of  data  and  the  transmission  of 
tnis  olocK  of  data  to  a  local  terminal  is  also  a  oata  transaction.  The  I-S/A 
AMPE  shall  process  data  transactions  FIFO  by  precedence.  The  type  of  traffic 
snail  not  be  considered  in  meeting  processing  requirements.  The  internal 
delay  for  tne  I-S/A  AMPE  to  process  a  data  transaction  shall  be  measured  as 
follows : 


a.  For  a  blocx  of  data  to  be  transmitted  to  the  network:  from  the 
receipt  of  the  last  bit  of  oata  to  rill  the  input  ouffer  or  a  receipt  of  a 
request  to  transmit  from  the  local  terminal  to  the  start  of  transmission  of 
the  first  packet  to  the  network. 

b.  For  a  group  of  packets  from  the  network  to  be  comoineo  and 
transmitted  to  a  local  terminal  as  a  block  of  data:  from  the  receipt  of  the 
last  packet  or  enough  packets  to  make  a  complete  block  of  data  until  the  first 
bit  of  that  block  is  transmitted  to  the  terminal.  The  maximum  allowable 
expecteo  traffic  processing  delays  for  data  transactions  are  specified  by 
precedence  as  follows: 
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PRELEOhiNCE 


r-'EAi.  PROCcSSiTiG  PROB  (t=T}=0.95 

TIME  E,t)  _ T _ 


Flasn  L  accve 

100 

mi  ■ 

1  lisec 

150 

mi 

1 lisec 

I:rjr;eai  ate 

2C0 

mi  ■ 

i  1 isec 

300 

iiii 

1 1 i sec 

Priori ly 

300 

mi ' 

i  lisec 

500 

mi  1 lisec 

Routine 

uCO 

mi ' 

1 1  isec 

700 

mi 

1 lisec 

3.b.^  CoiineciiL'n  Service 


Ccnnection  tin'e  is  liieasjrea  from  the  time  wnen  tne  originating  eser  of 
service  completes  tne  initiation  of  tiie  connection  request  until  the 
connection  is  completeo  and  tne  aovisenient  to  tne  originator  is  placeo  on  the 
line.  Tne  times  apply  to  completion  of  the  connection  internal  to  the  I-S/A 
AliPE;  that  is,  the  times  are  for  total  completion  of: 

Local  suoscrioer  to  local  subscriber  connection 

Local  subscriber  to  local  service  connection 

but  apply  only  to  the  internal  connection  between  the  local  user  or  local 
service  ana  the  THP  (TELAET)  for  those  connections  to  remote  network 
elements.  The  connection  time  incluaes  the  tim.e  requirea  to  verify  the 
connection  is  authorizea. 

In  the  event  the  connection  cannot  be  completea  because  the  aestination 
user  is  busy  at  an  equal  or  higner  preceoence  level,  then  the  originator  of 
the  request  shall  be  proviaea  with  the  busy  inaication  within  the  same  time  as 
specified  for  tne  connection  completion.  In  the  event  a  request  for  a 
connection  is  received  in  which  the  oestination  user  is  busy  at  a  lower 
preceaence  level  than  the  requested  connection,  then  the  new  connection  shall 
not  be  established  unless  the  request  is  of  flash  or  higher  prececence;  in 
which  case  the  lower  precedence  connection  shall  be  preempteo  ana  the  new 
(higher  precedence  level)  connection  established.  The  connection  times 
specified  do  not  incluoe  the  time  for  preemption  notification.  There  are  two 
oifferent  preemiption  notifications  aepenaing  on  whether  the  connection  is  for 
Formal  Message  Service  or  Data  Transactions.  It  the  connection  being 
preempted  was  carrying  Formal  Message  Traffic  then  the  preemption  notification 
shall  be  the  cancel  transmission  (CANTRAN)  sequence  specified  in  JANAP  128  (H) 
paragraph  330,  Cancelling  Transmissions.  The  contractor  shall  develop  the 
preemption  notification  message  for  Data  Transactions.  The  I-S/A  AMPE  shall 
satisfy  the  following  connection  requirements: 


PRECEDEfiCE 

MEAN  PROCESSING 

TIME 
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500  Milliseconos 
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Priority 

2  Seconos 

d  Seconas 

Routine 

2  Seconds 
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3.5.3  Storjce  ReaiJirenients 

The  I-i/A  AiTPE  shall  have  tht  capability  to  store  on-line  oata  to  snoport 
Plain  Lanquace  Aocress  to  SI  taoles,  SI  to  Logical  eccress  taoles,  rornal 
"cSScge  service  traffic  ano  otner  possiole  storage  requirecients  in  order  zo 
meet  all  I-S/A  mMFE  performance  requirements  simultaneously.  Tne  contractor 
snail  calculate  and  oefine  the  dirferent  storage  meaia  based  on  the 
requirements  specifieo  herein  and  tne  contractor's  system  oesign  and  submit 
T\.r  governiterit  approval. 

3.D.3.1  ^lai.n  Language  Acoress  yPLn,  to  SI  Taoie 

Tne  PLA  to  RI  table  snail  be  capable  of  iioloing  seventy-five  tnousano 
175,000)  entries  minimum,  expandaole  to  256,000  entries.  An  entry  shall  have 
an  expected  length  of  40  characters  and  a  maximum  length  of  62  characters. 

3 . 5 . 3 . 2  ^I  to  Logical  Adaress  Taoie 

The  RI  to  Logical  Acoress  table  shall  be  capaole  of  noloing  5000  entries. 
Entries  snail  be  lo  characters  in  length. 

3 . 5 . 3 . 3  On-Line  FMS  Storage 

Tne  expecteo  number  of  messages  per  day  is  thirty  tnousano  (30,000)  v;ith 
an  expected  length  of  2075  characters  (26  line  olocxs)  each.  Aocitional  data 
elements  are  required  to  be  stored  with  each  ir.essage  to  meet  tne  requirements 
of  3.5  System  Control  and  3.2. 1.6.2  History  Logs  and  Files.  The  on-line 
storage  capability  of  the  I-S/A  AMPE  shall  be  a  total  of  10  aays  on-line 
traffic  with  the  capability  to  expana  to  hold  up  to  sixty  (60)  aays  of  FMS 
traffic  by  the  simple  addition  of  more  storage  lueoia.  'Simple'  means  there 
shall  be  no  cnanges  required  to  the  operating  system  or  software  to  accomplish 
the  expansion.  Storage  media  shall  be  removable  to  facilitate  extenced 
storage  in  an  off-line  manner.  The  contractor  shall  aemonstrate  in  tne  oesign 
the  methoo  to  expand  on-line  storage  for  government  approval. 

3. 5. 3. 4  Search  and  Retrieval  access  Times 

The  I-S/A  AMPE  shall  support  searches  of  the  kinds  specified  in  3. 2. 1.7.1 
as  applied  to  the  on-line  FMS  storage  described  in  3. 5. 3. 3.  While  processing 
the  sustained  load  specified  in  3. 5. 1.2,  a  search  or  retrieval  of  any  kind 
snail  not  require  more  than  30  minutes  to  be  accomplished,  measured  from  the 
time  of  operator  initiation  or  service  request  until  the  last  unit  of 
information  is  queued  for  output. 

3 . 5 . 3 . 5  General  Storage  Requirements 

The  contractor  may  deem  it  necessary  to  provice  other  storage  capability 
in  order  to  meet  system  performance  requirements.  The  contractor  shall 
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speciry  in  :iie  systen;  desicn  ail  ti'.e  cifTerent  stjrage  n'edia  anc  tiieir 
speciric  Lie\sj. 

2. 5.-  PracessiiiG  Error  .-.aias 

Tiie  I-S/n  n,'"PE  siiall  ;r:eeL  che  following  processing  error  rate  rcpoireir.etiis 

Tiie  urooaoi  noy  or  irirococing  a  caua  error  .-.itniit  me  I-S/A  er,PE 
siiall  Pe  less  cnar,  one  occurrence  in  10^-  cnaraccei's. 

'lie  prcoacility  or  transmission  of  errors  originating  .vitnin  tiie 
1-S/A  mMPE  snail  be  less  than  one  occurrence  in  ic'*-  characters. 

Tne  probability  of  messages  being  misrouteo  by  action  or  the  I-S/A 
aMPE  shall  be  less  than  one  occurrence  in  lO^'f  messages. 

The  probability  or  messages  oeing  lost  by  action  of  the  I-S/A  AMPE 
shall  be  less  tnan  one  occurrence  in  10^“^  messages. 

3.5.4. 1  UnoetectcG  Error  Rate 

The  probability  of  any  of  the  above  errors  occurring  witnout  oetection  and 
iiOtif ication  of  supervisory  personnel  shall  be  less  tnan  one  occurrence  in 
1012  events . 

3.0.5  Avai lability 

Hvailability  snail  be  considerea  of  priir.e  importance  in  the  uesign  ana 
manufacture  of  the  I-S/A  mMPE.  The  I-S/A  AMPE  snail  automatically  receive, 
process,  ana  transmit  user  transactions  in  accoroance  with  the  functional 
requirements  specifieo  herein,  and  shall  be  capable  of  performing  these 
functions  concurrently  24  hours  per  day,  7  oays  per  week.  Availability 
requirements  shall  meet  or  exceed  collectively  the  following  quantitative 
values: 

Availability  to  operate  without  loss  of  service  to  a  specific  circuit 
of  at  least  0.9995 

.  Availability  to  serve  75%  or  more  of  all  circuits  of  at  least  0.9995 

Availability  to  process  traffic  on  any  non-failed  circuit  of  at  least 
0.9995. 

3. 5.5. 1  Recovery 

The  I-S/A  APiPE  shall  provide  secure  automatic  restart  and  recovery 
procedures  (see  Section  3.4)  following  a  haroware  malfunction  or  failure 
condition.  The  expected  recovery  time  of  the  I-S/A  AMPE  shall  have  a  mean  of 
at  most  5  minutes  and  probability  of  at  least  0.95  completion  of  recovery  in 
10  minutes  or  less,  buring  tnis  recovery  period,  the  I-S/A  AMPE  shall 
automatically  perform  the  functions  necessary  to; 

.  Replace  or  restore  hardware  as  necessary  to  configure  an  operational 
system 
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Reconstruct  active  processing  files  to  their  status  prior  to  failure 

.  Restore  all  other  software  to  its  status  prior  to  failure 

No  Formal  Message  Service  traffic  that  has  been  accepted  for  processing 
prior  to  the  time  of  I-S/A  AiMPE  failure  or  malfunction  shall  be  allowed  to  be 
’ost.  There  is  no  requirement  for  protection  of  Bulk  Data  Transfer  Traffic 
iring  recovery.  All  directly  connected  users  of  the  I-S/A  AMPE  shall  be 
Jtomatically  advised  of  any  failure  and  recovery  wherein  there  was  a  possible 
denial  of  service  or  loss  of  data. 


3-5.6  Degraded  Ooeration 


In  the  event  of  a  hardware  failure,  unavailable  output  circuit,  or  other 
condition  that  decreases  the  processing  capability  of  the  l-S/A  AMPE  or 
reduces  throughput,  a  degraded  mode  of  operation  shall  be  available.  The 
degraded  mode  of  operation  shall  process  input  data  according  to  precedence 
(as  described  in  3. 2. 1.3. 4  and  3. 2. 2. 5-1)  and  capability,  with  processing  of 
lower  precedence  traffic  being  denied  as  processing  capability  decreases.  In 
this  degraded  mode  of  operation,  t.he  I-S/A  AMPE  shall  process  the  highest 
precedence  incoming  traffic  to  the  ma.ximum  extent  possible.  Any  degration 
operation  shall  not  violate  the  requirements  of  Section  3-4. 
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3 . 6  ReC’j i re'reMts  for  Software  anc  Firir.vare  Jeve  1  crrfient 

All  softv.are  ana  firinv.are  cevelopec  for  tiie  I-S/A  ni-iPE  shall  a'eet  the 
req.- ire.'.etits  spcairieo  celov:.  Soriv.'are  aitc  fin'v.are  snail  encorpass 
cpet'ac ional  progress,  ciagnostic  prograr.s,  operating  test,  eiiiulaticn  rinr.vare, 
aiiG  all  support  sort.vare. 

All  soTtivare  ana  r inaware  the  contracter  cevelops  or  ^ses  tor  tne 
■"aintenance,  operation,  arc  testing  ur  trie  I-S/.n  nMPEs  shall  be  aelivereo  to 
ere  oecenre  the  property  of  the  Gcvernrre.nt. 

nil  security-relatec  soft.vare  anc  firmware  shall  be  classifieo  in 
accordance  with  tne  Security  Classification  Guidelines. 

If  the  I-S/A  AMPE  is  implemented  using  firmvvare  developed  by  the 
contractor,  the  contractor  shall  provide  an  assenibler  and  simulator  as 
software  ueliveraole  items.  Tne  assembler,  siinulatcr,  and  any  other  micro 
support  software  developed  or  used  shall  be  host  independent. 

nil  software  and  firm.ware  shall  be  designed  and  developed  in  accordance 
witn  MIL-STD-433,  supplemented  by  MIL-STD- 1679,  and  the  security  requirements, 
Section  3.4.  In  addition,  the  requirements  set  forth  below  shall  apply.  Any 
deviation  from  these  requirements  shall  require  approval  by  the  I-S/A  AP'.PE 
Program  .‘'.anager.  The  following  paragrapiis  apply  to  specific  wording  or 
requirements  of  l-.IL-STD- 1679. 

2.6.1  nooif ications  to  WIL-STD-1579  jNavy) 

The  contractor  snail  comply  with  all  requirements  of  ^iIL-STD-1679,  as 
modified  below. 

a.  To  improve  readability  and  clarity,  the  contractor  may  replace 
the  pnrase  "weapon  system"  witn  tne  phrase  "com.mun ications  system"  throughout 
MIL-STD- 1 679 .  hote,  however,  that  Section  3.1  of  MIL-STD-1679  includes 
communications  systems  within  the  scope  of  the  definition  of  "weapon  system". 

b.  Page  6  Section  4.3:  delete  first  sentence  and  replace  with  the 
following:  "Communication  system  software  shall  be  coded  in  a  high  order 
programming  language  (HOL)  approved  by  the  procuring  agency." 

c.  Page  10  Section  5.3.6:  replace  sentence  with  the  following: 
"Recursive  procedures  or  routines  shall  not  be  used  unless  approved  by  the 
government  on  an  individual  basis." 

d.  Page  15  Section  5.5.3:  replace  sentence  with  the  following: 
"Communication  system  software  shall  be  coded  in  a  high  order  programiming 
language  (HOL)  approved  by  the  procuring  agency." 

e.  Page  16  Section  5.5.4:  Add  the  following  at  the  ena  of  the 
paragraph:  "The  use  of  patching  shall  be  minimized." 

f.  Page  16  Section  5.5.5:  Delete  section. 

g.  Page  16  Section  5. 5.6.1  line  4;  delete  the  phrase  ",  if 
avai laole. " 


h.  P^ge  21  Section  5.10.2.2:  rleleto  the  last  sentence. 

i.  Page  22  Section  5.10.3.1:  replace  section  with  the  following; 
"There  shall  be  cero  unresolved  software  errors." 

3.6.2  arv^_?ircv.;^:^r^e  Management 

a.  The  contractor  shall  institute  a  software  and  firmware  quality 
as3-irar.ce  program  in  accordance  with  MIL-STD-167'^  (See  Section  4). 

b.  The  contractor  shall  perform  conf iguration  management  in  accordance 
with  MIL-STD-167d  (See  4.1.1). 

c.  The  contractor  shall  perform  sufficient  development  testing  to 
realistically  measure  program  performance  and  development  progress  (See 
Section  4 ) . 

d.  The  contractor  shall  produce  docu-ments  to  substantiate  security 
verification  prior  to  the  Program  Design  Specification  (PDS)  DI-E-2138 
specified  in  paragraph  e.  Required  documents  are  specified  in  Section  3.4. 

e.  The  contractor  shall  produce  the  following  documents  in  accordance 
with  MIL-STD-1679 ; 

Contract  Data  Requirement  DID  Document  Order 


Software  Development  Plan 
Software  Quality  Assurance  Plan 
Software  Configuration  Management  Plan 
Program  Performance  Specification  (PPS) 
Program  Design  Specification  (PDS) 
Program  Description  Document  (PDD) 

Data  Base  Design  Document  (DBD) 

Computer  Program  Test  Plan 
Computer  Program  Test  Specification 
Operator's  .Manual  (OM) 

System  Operator's  .Manual  (SOM) 
Preliminary  Program  Pacl<age  Document 
Computer  Program  Test  Procedures 
Computer  Program  Test  Report 
Software  Change  Proposal ( SCP ) /So ftware 
Enhancement  Proposal  (SEP) 

Computer  Software  Trouble  Report  (STR) 
Fi.nal  Program  Pac)<age  Document 


DI-A-2176 

DI-R-2174 

DI-E-2175 

DI-E-2136 

DI-E-2138 

Dl-S-2139 

DI-S-2140 

Dl-T-2142 

Dl-E-2143 

Dl-M-2145 

DI-M-2148 

DI-S-2141 

DI-T-2144 

DI-T-2156 

DI-E-2177 

DI-E-2178 

DI-S-2141 


1 

1 

1 

2 

3 

3 

3 

4 

5 
5 
5 

5 

6 

7 

as  needed 

as  needed 

8 


f.  The  contractor  shall  provide  step-by-step  operating  instructions  for 
message  preparation,  retrievals,  traffic  management  and  all  facets  of  on-line 
and  off-line  system  operations. 
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The  above  itev.s  shall  be  produced  and  delivered  in  the  order  specified. 
Program  design  docamentation  (POS,  PTD,  D3D)  shall  be  completed  prior  to 
initiation  of  co.ling.  See  4."^  for  security  related  quality  assurance. 

3.6.3  Programming  Requirements 

In  addition  to  the  programming  requirements  of  MIL-STD-1679  and  the 
Security  Section  3.4.,  the  folloving  shall  apply: 

3,  •  X  “  3  ^  A  A^'l  ?H  30  *iV  3  sH  3  a.  ^  ^  t  *^i  i.n  H  '"I 3^"^  '  T*. 

accordance  with  DoDI  5000.31.  The  high  order  language  selected  by  the 
contractor  shall  be  approved  by  the  Government  Program  Idanager  prior  to  its 
use.  Minimal  use  of  assembly  language  is  permitted  when  absolutely  necessary 
due  to  software  dependencies  on  target  machine  architecture;  however,  no  more 
than  10  percent  of  the  I-S/A  AMPE  software  written  in  assembly  language  is  a 
goal . 

b.  Software  and  firmr/;are  design  requirements  shall  be  developed  by 
a  systematic,  top-do^'m  methodology. 

c.  The  contractor  shall  implement  code  in  a  top-down  manner  that 
permits  incremental  development  and  test  of  software. 

d.  The  contractor  shall  utilize  structured  programming  techniques. 

e.  The  contractor  shall  utilize  common  code  and  common  procedures 
to  the  maximum  extent  practical . 

f.  Software  procedures  and  routines  shall  be  serially  reusable. 

g.  Instruction  modification  during  execution  shall  be  prohibited. 

h.  In-line  documentation  shall  be  included  in  software  and  firmware 
and  shall  follow  those  guidelines  set  forth  in  3.6.4 

i.  Software  procedures  and  routines  shall  use  the  general  registers 
(or  other  conventional  methodologies )  in  a  uniform  manner  for  procedure  and 
routi.ne  linkage,  parameter  passing,  and  error  information. 

3.6.4  Doc 'jmentat ion  Requir ements 

In  addition  to  the  documentation  requirements  of  MIL-STD-1679  and  the 
security  Section  3.4.,  the  following  shall  apply; 

a.  The  contractor  shall  docxament  software  and  firmware  in  a  clear 
a.nd  concise  manner. 

b.  Each  software  and  firmware  module  shall  contain  a  preamble  of 
comments  describing  its  function,  interfaces,  inputs,  outputs,  number  of  lines 
of  code  and  any  other  information  deemed  necessary  to  the  understanding  of  the 
module.  In  addition,  the  preamble  shall  contain  a  list  of  those  modules  which 
call  the  described  module  and  those  modules  called  bv  the  described  module. 


c.  Software  ana  fir::;ware  shall  use  Slock  coir.ir,ents  wiierever 
cppi'upriate  to  air.pl'ify  the  leaning  of  sections  of  coee.  Block  ccip-tnts  siiuuic 
not  i.erely  restate  in-ii;.e  cor'.ipents  but  snculc  explicate  the  meaning  of  the 

C  CCC6. 

u.  Block  comments  anc  preambles  snail  be  celineatea  from  the 
soTt'ware  and  firmware  oy  special  character  sequences  for  increased  readability 
and  possiole  later  extraction. 

e.  In-line  C'''-'':r;nts  shall  be  clear  and  inrormative,  anc  tney  snail 
nut  sim.plj  restate  tne  instruction.  In  the  case  of  asssi.ioly  ana  rira.v.are 
assemoly  language  programs,  an  in-line  comment  snail  oe  piaceo  on  eacn  line  of 
code. 

3.7  Hardware  System  Requirements 

3.7.1  Haraw  are  Oef i n i t i on 


Tne  I-S/A  AImPE  hardware  shall  consist  of  data  processing  equipment  ano 
peripherals  necessary  to  perform  message  storage  ana  s.vitching,  operator  and 
service  position  controls  and  displays,  fault  isolation  ano  correction 
capability  and  required  connectivity  among  these  elements  to  meet  the 
description  anc  requirements  specirieo  in  this  document.  Tiie  I-S/m  Af.PE 
development  snail  not  induce  cryptograpnic,  terniinals,  or  transmission 
multiplex  equipment.  Except  where  otherwise  statec,  the  I-S/A  Ai-IPE  equipment 
snail  meet  ttie  requirements  of  HIL-E-AISSE ,  General  Requirements  Tor  Ground 
Electronic  Equipment,  MIL-STD- 1S8- 1 14,  Electrical  Cnaracteristics  of  Digital 
Interface  Circuits,  and  MlL-STD-183-100,  Common  Long  Haul  and  Tactical 
Communication  System  Technical  Standaros. 

3.7.2  fiodu  1  ari  ty 

The  I-S/A  Ai'iPE  equipment  shall  be  modular  in  nature  to  permit  a  fully 
functional  I-S/A  AMPE  to  be  installed  at  each  location  that  will  be  efficient 
in  utilization  of  resources,  be  a  readily  expandable  facility,  ana  permit 
graaual  aegraaation  in  the  event  of  component  failure(s). 

3.7.2. 1  Reliability  Through  Modularity 

The  modularity  of  the  I-S/A  AMPE  equipment  shall  be  implemented  in  a 
manne’'  that  will  enhance  the  reliability  of  the  overall  performance.  Failure 
of  a  module  shall  not  cause  either  otner  modules  performing  the  same  function 
or  other  modules  interfacing  the  failed  module  to  become  inoperable. 

Sufficient  modules  shall  be  used  to  duplicate  functions  so  failure  of  a  single 
module  shall  not  cause  a  complete  I-S/A  AMPE  outage. 

3. 7.2.2  Sizing 

The  I-S/A  AMPE,  with  its  modular  nature,  shall  be  implemented  in  such  a 
manner  that  an  installed  I-S/A  AMPE  can  change  sizing  in  terms  of  subscriber 
connectivity  and/or  throughput  capability  without  replacing  or  grossly 
modifying  existing  equipment.  Further  the  I/S-A  AMPE  shall  have  an  inherent 
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growth  reser-ze  of  25%  (percent)  at  IOC.  The  contractor  shall  def.onstrate  how 
the  design  provides  for;  increase  in  subscriber  terminations,  increase  in 
throughput,  and  the  25%  inherent  growth  resef/e.  The  minimum  number  of 
subscriber  terminations  shall  be  thirty-two  (32)  expandable  in  increments  of 
15  up  to  64  subscribers. 

3.7.3  Memory 

Criteria  of  interest  for  the  I-S  A.MPS  me.mory  are  marcimum  expansion  size 
of  physical  memory,  maximum  addressability  capability  of  virtual  memory, 
increment  size,  nominal  cycle  time,  and  cost  per  bit.  The  hardware  structure 
of  the  I-S/A  A.MPE  memory  shall  provide  for  protection  against  errors  and 
memory  loss  of  critical  data  (program,  routing  tables,  etc.).  For  example, 
this  may  be  implemented  with  nonvolatile  memory. 

3 . 7 . 3 . 1  In-Trans  it  Sto r'^ge 

In-transit  storage  for  the  I-S/A  A*dPE  shall  be  developed  such  that  there 
will  be  no  loss  of  messages  d^ie  to  a  hardware  or  software  failure.  The 
storage  is  to  be  multi-tiered  to  permit  rapid  access  for  current  messages 
being  processed  and  a  secondary  storage  for  preser-zing  traffic  on  queues  while 
a  circuit  is  busy  and  not  loading  the  main  memory  or  processor,  and  some  form 
of  off-line  storage  which  does  not  require  rapid  access  for  historical 
purposes . 

3.7. 3. 2  Message  Storage  for  Retrieval 

Sufficient  capacity  of  storage  or  capability  in  terms  of  off-line  storage 
shall  be  developed  for  the  I-S/A  AMPS  to  preserve  for  a  period  of  up  to  60 
days  (determined  on  a  site-by-site  basis)  the  traffic  processed  by  the  I-S/A 
AMPE.  This  storage  shall  be  in  a  form  that  is  usable  on-line  as  specified  in 

3. 5.3.3. 

3 . 7 . 3 . 3  Memory  Access 

The  I-S/A  A.MPE  hardware  implementation  shall  be  of  a  nature  which  enhances 
the  capability  to  restrict  access  to  certain  portions  of  memory,  such  as  a 
ring  architecture. 

3.7.4  Fault  Isolation  and  Correction  Capability 

The  I-S/A  AMPE  FICC  shall  provide  automatic  testing  and  a  default  manual 
testing  capability,  circuitry  termination  and  rerouting,  and  reporting.  The 
FICC  shall  be  designed  and  implemented  as  an  integral  part  of  the  I-S/A  AMPE. 
An  objective  of  t.he  FICC  is  to  minimize  the  human  actions  required.  The  FICC 
shall  comply  with  MIL-STD-1B8/310,  Subsystem  Design  and  Engineering  Standards 
for  Technical  Control  Facilities.  The  I-S/A  AMPE  FICC  shall  provide  on  a  per 
termination  basis: 

o  Circuit  configuration  data  base; 

o  Immediate  alarm  indication  of  circuit  degradation  or  outage; 
o  Rapid,  remote  access  to  any  circuit  segment  for  loopbac)?  and  testing: 
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0  Autoiracic  fa^i::  isolation  osing  locpDacK,  remote  test  ecoip.’rent  and 
soTtivai'e  routines; 

0  Ke^strcr^e  speco  or  patcning  (replacii.:  i  nci  vicua  I  cerective  eq^ip.iient 
or  raci 1 i ties ] ; 

0  Positive  verirication  of  repairec  operation; 

G  uoncri-iijn  c~  iicOtrSi 3r y  *035  an c  c^nrc fe  arer  G'Sod  cc  rscii^tdoO  ntft‘.*or< 
r::or.  5Ge  dn:. 


3.7.4. 1  Connection  ..aoaoilit> 

Tne  I-S/A  AMPE  FICC  shall  provide  for  the  secure  termination  cf 
comniunicatiens  circuits,  associated  cryptographic,  moaem  and  otner  related 
communications  naroware  associateo  i^itn  per  line  communications  circuits  and 
shall  provice  "normal  througn"  ana  reconnection  capaoilities  for  routine  ana 
failed  hardware  situations.  See  paragraph  3.3.6  for  further  recu irements . 

3. 7 .0 .2  Testing 

Tne  I-S/A  APiPE  FICC  shall  provice  automatic  testing  with  manual  testing 
falloaCK  capaoility.  nutomatic  testing  snail  enaole  the  operator  to  perform 
automatic  line  testing  (e.g.,  to  specify  the  line  ana  test  to  be  performeo) 
ana  ootain  tne  results  of  tnat  test  from  a  console  position.  The  console 
snail  provice  the  capability  of  selecting  a  circuit  in  the  Rea,  Slack,  or 
moaem  area  for  testing;  however  security  concerns  require  strict  segregation 
or  Rea  ana  BlacK,  tnus  the  aesign  shall  ensure  tnat  the  FICC  is  working  Rea  or 
Black  but  never  botn  simultaneously.  Manual  Testing  provides  the  operator  the 
capability  ana  test  equipment  to  physically  access  lines  and  perform 
appropriate  tests.  Test  equipment  shall  meet  minimum  performance  stancards  of 
DCAC  300-175-9.  The  I-S/A  AMPE  FICC  shall  nave  rapia,  remote  access  to 
circuit  segments  for  loopback  and  testing,  ana  automatic  fault  isolation  using 
loopback,  remote  test  equipment  and  software  routines. 

3. 7. 4. 3  Reporting 

The  FICC  will  be  responsible  for  reporting  as  required  by  DCAC  310-55-1. 
Therefore,  the  FICC  shall  provide  a  semi-automatea  capability  to  provide 
required  reports  (See  paragraph  3.3.5). 

3.7.5  Operational  Characteristics  (See  aaoitional  aiscussion  in  Section  3.4, 
Security ) 

3 . 7 . 5 . 1  Avai lability 

The  capability  of  the  I-S/A  AMPE  system  to  perform  traffic  nandling 
functions  shall  be  a  minimum  of  99.95  percent  with  tne  I-S/A  AMPE  in 
continuous  operation.  This  may  be  accomplished  by  reaunaancy  of  processors. 
Redundant  processors  may  be  implemented  using  one  processor  for  communications 
functions  while  another  performs  background,  statistical  and  other 
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'nousekeeping'  functions,  operating  processors  in  parallel,  or  splitting 
processing  among  multiple  processors. 

3.~.5.c  R  e 1 i ao i 1 i ty 

Tne  I-S/A  AMPE  equipment  snail  have  features  to  maintain  high  levels  of 
reliability  in  terms  of  both  maintaining  operation  ana  maintaining  correct 
functioning.  Tins  will  be  iniplementec  through  mechanisms  for  oetecting 
rai  lures  s^cn  as  a  v.atciiccg  timer,  automatic  restarts  ana  recovery,  capaoility 
to  autcmatital ly  reconfigure  and  operate  in  a  oecracec  "'oce,  internal  cata 
cnecKS  ror  cata  transfers,  ana  sufricient  I/O  channels  ar.c  chec.vinc.  Failure 
or  a  single  peripheral  snail  not  stop  operations. 

3. 7. 5.3  Maintainabi 1 i ty 

The  I-S/A  AWPE  shall  be  modular  in  both  logic  and  hardware 
implementation.  This  will  assist  in  providing  a  capability  to  perform 
maintenance  on  a  portion  of  the  equipment  while  tne  remainder  is  still  in 
dperation.  maintainability  features  siiall  be  previcee  to  maintain  a  Mean  Time 
to  Repair  (MTTR)  for  any  failure  of  less  than  1  hour. 

3. 7. 5. A  Interrupt  Structure 

Due  to  the  multilevel  precedence  nature  of  traffic,  the  processor  should 
possess  a  multilevel  vectored  priority  interrupt  miechanism  with  context 
Switching  hanaled  in  hardware  under  control  ot  the  trusted  computer  base. 

There  snail  also  oe  a  secure  capability  to  innioit  interrupts  to  prevent 
erroneous  operations  during  operations  such  as  updating  routing  tables.  See 
Section  3.4,  I-S/A  AMPE  Security. 

3. 7. 5. 5  Instructions  in  Haroware 

To  improve  reliability  and  minimize  operation  times,  implementing 
operations  in  haroware  or  firmware  shall  be  implementeo  where  it  is  feasible 
ana  ooes  not  detract  from  system  flexibility,  such  as  code  conversions, 
recognition  of  special  characters,  parity  or  CRC  checking,  flag  oetection,  and 
operations  with  bit  transparent  protocols. 


3. 7, 5.6  Cycle  Times 


A  significant  criteria  is  the  instruction  operation  tiuie  for  operations 
which  will  be  used  repetitively  in  the  I-S/A  hKPE  software. 
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3.S  Oesio.n  aiic  Develcprierti  (rvlso  see  SectiLri  3.“^,  I-S/A  mi^FE  Security) 
j  . 3 . 1  i''  ecu  1  ar  i  c,y 

T'le  concept  of  .’’oculariiy  sAail  Oc  consicereu  .,f  pric-e  i.'.portancc  in  K.e 
ucsicn  atiu  oevelopn:c;nt  ot  tne  I-S/r^  r^MPE,  '''.ctiu lari ty  or  sett.-, 'are,  hareware, 
anc  t’.r,.il  pert:  >'",ar,ce  siijil  oe  r  .i^irec  '  ;  '-nit  tiilorir;o  of  eacn  i-S/n 

-i-'FE  to  tne  rec..irtr'tet‘is  *  t.ie  ,.ci  r*-.-  r  ,■  ter--' i 

- 1 -it'C  ■  »  .;  t  ;  - ; .  tI'T.'  .  J  •  -  z  .  - 

I-i,  rA  rti'.Fc.  CGtit  iguracion  snail  oe  rep...',rcu  ic  incluce  only  cnose  service 
processing  runctions  necessary  to  support  tne  nct.-.civ  services  proviOec,  tnose 
conimunications  processing  functions  necessary  to  support  tne  user  coit.munity 
and  the  service  functions  provided,  and  tnose  con^tiuni  cat  ions  interface 
functions  necessary  to  support  tne  connuni cat  ions  lines  ano  user  terminal 
cevices  connected  to  the  I-S/^  aF'FE.  Tne  funciional  structure  of  a  given 
I-S/A  /AiMPE  shall  oe  tailoraole  to  tne  req-.irentents  or  tne  I-S/A  /-.MPE  users, 
noivever,  tne  performance  or  provision  or  cacn  function  incluoeo  in  tnat  I-S/A 
n.'-lPE  snail  be  accomplished  in  accordance  .-.ion  tne  requirements  of  tne 
functional  specification. 

3 • o . u  Softucre  resign 

The  sort'/, 'are  design  for  the  I-S/A  AIFPE  shall  be  developed  under 
disciplined,  top  ocv,n,  structureo  programming  techniques  in  accordance  with 
■•113-570-1679  and  OoD  Directive  5000.29.  Stanaaro  software  shall  be  developed 
using  an  approved  High  Oroer  Language  (HOL)  (See  3.6.3)  or  give  sufficient 
justification  to  the  Program  Manager  for  using  a  non-approved  HOL.  The 
soft/zare  shall  be  designed  to  be  expanoaole  anc,  to  the  mdxin,um  extent 
practical,  independent  of  tne  venoor  hardware. 

3.3.3  Haru'ware  Design 

Design  and  construction  of  the  I-S/A  AMPE  snail  demonstrate  a  quality 
commensurate  //ith  the  best  commercial  design  practices.  The  hardware  shall  be 
modular  in  nature  allowing  graceful  growth  and  enhancements  and  minimizing 
field  maintenance.  The  haroware  shall  also  be  designed  to  minimize  the  amount 
of  hardware  modification  needed  to  satisfy  any  required  I-S/A  AMPE  packaging 
configurations  (e.g.,  rack-mounted,  stand  alone,  or  transportable  units). 
Maxirnum  use  shall  be  maoe  of  state-of-the-art  technologies  available  at  the 
time  of  procurement  in  order  to  fully  exploit  the  performance,  reliability, 
cost,  size,  weight,  logistics,  and  maintenance  aovantages  those  technologies 
may  offer.  Replacement  modules  shall  be  utilized  whenever  practical  to 
promote  ease  of  maintenance,  reouce  downtime,  and  lower  costs.  The  I-S/A  AMPE 
shall  be  provided  with  a  computer  power  center  compatible  with  the  I-S/A  AMPE 
haroware  proposed  at  each  site.  Tne  computer  power  center  shall  include  as  a 
minimum  an  isolation  transformer,  circuit  breakers,  panelboards,  computer 
Automated  Data  Processing  Equipment  (ADPE)  branch  circuits,  shunt  trip 
breakers,  transient  protection,  and  meters. 
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8. a 


anoardization 


Tne  I-S/A  AMPEs  shall  be  developed  with  a  maximum  degree  of  conmonality  in 
hardware  and  software  and  with  a  degree  of  standardization  required  to  insure 
commonality  without  compromising  operational  effectiveness. 
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Hu::iaii  Perrorr.ance/human  Enaineeriiia 


3.S.: 


nelevanc  nj'nan  ractcrs  wnicri  can  ce  icentiriec  i.i  tne  context  or  tne 
■  an  ■•"acnine  interface  runctions  sna]i  ae  cefineo  anc  appliiiC  in  acccrcance 
,vitn  tne  tscnniGucS  cescrioea  in  appropriate  paragraphs  or  IL-H-asSoE .  nli 
huii’.an  Engineering  in, pots  shall  o.eet  the  applicaole  criteria  of  MIL-STD-N72 
ana  other  criteria  specitieo  in  tne  Interface  Control  [;ocLi[,.ent . 

3 . ^  aintai r at i  1  i tv  anu  Logistics 

I'.ai n tainaoi  1  i t>  snail  oe  ccnsioerec  of  pri:r.e  irtportance  in  tne  aesign  ana 
laanor actore  of  tne  I-S/A  nl-'PE.  Maintainability  requirerrents  shall  comply  '.vith 
1X11-570-470.  Maintainaoi  1  i ty  requireii^ents  shall  aohere  to  the  following 
guiael ines : 

Maintenance  proceaures  shall  be  designeo  to  be  as  simple  and 
efficient  as  possible. 

.  ^  maintenance  concept  snail  be  aevelopeo  whereby  maintenance 

responsibility  is  asso.xed  by  on-site  personnel  to  the  fullest  extent 
possible. 

Secure  maintenance  procedures  shall  be  emphasized. 

A  preventive  maintenance  program  snail  be  definea  ana  quantitative 
limitations  shall  be  established  on  the  frequency  of  requirea 
preventive  maintenance. 

The  Mean  Time  to  Repair  failures  which  woulo  cause  loss  of  service  to 
all  circuits  shall  not  exceed  one  (1)  hour. 

An  Integrated  Logistic  Support  (ILS)  Plan  snail  be  prepared  as  part  of  tne 
I-S/A  AMPE  oevelopment  process.  The  ILS  Plan  shall  adtiere  to  the  following 
organizational  and  conceptual  guioelines. 

3.y.l  .Hardware  Maintenance  (Also  see  Section  3.4,  I-S/A  AMPE  Security) 

The  I-S/A  AMPE  equipment  shall  be  reaoily  installed  and  maintainea.  It 
snail  be  subject  to  repair  at  three  levels  as  follows: 

a.  Organizational  Level  Maintenance.  This  level  of  maintenance  is 
defined  as  the  maintenance  which  is  the  responsibility  of  and  performed  by 
organizational  personnel  with  assigned  equipments.  It  shall  consist  of 
inspecting,  servicing,  lubricating,  adjusting,  and  replacing  printed  circuit 
cards,  subassemblies,  and  assemblies. 

b.  Intermediate  Level  Maintenance.  Intermediate  level  maintenance 
shall  consist  of  the  repair  of  faulty  components  and  assemolies  not  considered 
repairable  at  the  organizational  level.  It  shall  include  printed  circuit 
Doaro  component  rep  1 acenient ,  calibration,  adjustments,  soldering,  and  any 
requ ired/scheauled  preventive  maintenance  actions. 
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c.  ^epct  Level  .Xaiiitenance.  Depot  level  maintenance  shall  consist 
CT  all  repairs  anc  overnaal  not  consiaereo  or  cesignatecl  as  repairaole  at 
iov.cr  mairitenance  levels.  Inis  service  shall  te  performec  by  cesignatec  cepot 
repair  r'aci  1  i  ties  . 

3.9.L  ^^iaintel1al1ce  Concept 

Xodule  replacement  at  tne  organizational  level  snail  be  the  maintenance 
concept  to  be  applieu  to  the  I-S/A  Af-PE.  ■■ocale  repair  ar.v.  parts  replace-cht 
snail  oe  accotplisr.ed  in  accorcance  witti  i.e.i  or  this  soeci  r  ication .  -  ievei 

of  repair  analysis  shall  te  perrormea  in  a  later  pnase  or  progrem  ee'. elopPient 
ana  shall  oe  asec  to  j^stiry  a  decision  to  repair  or  ciscaro  a  defective 
module,  printeo  circuit  ooaru  or  component  tor  each  maintenance  action  at  each 
level  of  maintenance.  Built-in-Test  and  diagnostics  snail  be  used,  where 
feasible,  for  rapid  fault  isolation.  Fault  isolation  shall  be  acnievable  to 
tne  lowest  replaceaole  module.  Use  of  multipurpose  test  equipment  shall  be 
emphasizeo  to  reduce  numoer  ana  types  of  cn-site  inventory. 

3.9.3  Software  Maintenance  Concept 

/After  IhS  Phasing  Group  processing,  software  changes  will  oe  forwarded  to 
the  LML'/PWO  for  action.  Tnrougn  the  Configuration  Control  Board  (CCb),  the 
LXD/PXO  will  establish  procedures  for  handling  all  aspects  of  proposed  system 
software  modifications,  testing  and  certification  of  approveo  software 
Changes.  These  procedures  will  include  initial  review  ano  approval  or 
disapproval.  Responsibility  for  implementation  of  approved  changes  will 
resice  with  a  centralized  authority  to  be  included  in  the  Program  Management 
Responsibility  Transfer  (PMRT)  ano  Systems  Operational  Concept. 

3.9.3. 1  I-S/A  AMPE  Test  Bed 

Experience  with  AUTODLN  has  clearly  dem.onstrateo  the  need  for  centralized 
life-cycle  software  management  and  control,  the  need  for  a  software 
development  ano  testing  facility,  ano  the  advantages  of  proximity  between  the 
software  support  staff,  the  management  staff,  ana  the  test  facility.  This 
permits  maximum  responsiveness  to  operational  needs  regarding  development  and 
test  efforts  ano  reduces  costs  associated  with  travel  ana  time.  A  centralizea 
engineering  and  software  development  test  bed  facility  is  Oefinitly  required 
for  life-cycle  support  of  fielded  I-S/A  AMPE  installations  and  will  be 
provided  by  the  LMD/PMO  as  part  of  the  I-S/A  AMPE  Program.  This  facility  will 
be  referred  to  as  the  hWPE  Support  Facility  (AMPE  S/F).  The  LMD/PMO,  througn 
tne  contractor,  will  be  expected  to  provide  the  first  year's  support.  How  the 
final  life-cycle  support  in  this  area  is  accomplished  will  be  decided  by  the 
LMD  through  coordination  with  DCA  ano  the  S/As.  The  decision  will  be 
reflected  in  the  PMRT  ano  must  include  a  trade-off  concerning  contractor 
versus  government  support  and  must  consider  possible  LMD  delegation  of  this 
responsibility  to  other  Services  and  Agencies.  O&M  planning  figures  and  an 
organizational  concept  plan  will  be  provided  by  the  LMD/PMO  as  an  input  to  the 
DCA  Five  Year  Plan  (FYP). 

3.10  Design  Priorities 

while  all  requirements  levied  on  the  I-S/A  AMPE  are  important  and  must  be 
fully  complied  with,  tne  following  requirements  should  receive  first  priority 
in  design  and  implementation. 
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3.10.1  SecLiP  i  ty 


Tiia  DoC  ■•:air..al  0-5030. 53.’'  security  aesign  is  vital  to  the  DSSCS/GENSc.k 
acoreci CctiLn/certiticaticn  process. 

3.10.2  Flexiti lity 

The  Todolanty  of  tne  l-S/i^  .-.OPE,  ootn  haro.vare  ano  software,  shculo  be 
sscii  tnai  tn=  I-S/A  .-,X?E  is  capable  of  a  secure  srcocn,  easy,  crvoli. ti^ncry 
cnaiice  a, 'Id, or  arc.-.to  ,see  Secticr.  3.^,  I-S,',-  .-'-'Pl  Security^,  -^ra-.^r.  ahe 
I-5/ri  m'lPc  cesiun  snculo  leno  itself  to  ocan  riAto  aiiu  reiocaaauit 
appl ications . 

3.10.3  Performance 

The  design  shoulo  explicitly  address  performing  service  functions  and 
features  in  a  uay  tnat  least  impacts  t.he  aoility  or  the  I-S/A  AOPE  to  perform 
its  total  set  of  requirements.  Aspects  sucn  as  overflow  and  routing  shoulo  be 
performeo  with  minimal  numan  intervention.  To  tne  maximum  extent  practicaole 
functions  ana  features  snoulc  be  performeo  via  computing  power  vice  human 
intervention . 


3.11  Government  Furnisneo  Property  (GFP) 


3.11.1  Oesian  Assistance 


The  government  has  available  a  numoer  of  computer  caseo  tools,  such  as 
simulation  programs.  Prior  to  either  procuring  or  oesigning  soffware  tools, 
the  contractor  shall  consult  with  the  government.  However,  it  is  not  the 
intention  of  the  government  to  provioe  computer  time  for  the  use  of  any 
software  tools. 


3.11.2  Hardware  and  Software 


For  the  effort  to  prepare  Type  B  development  specifications,  the 
government  Goes  not  anticipate  provioing  any  GFP.  However,  oepenoing  on  the 
oesign  approach  adopted,  GFP  could  be  required  for  the  implementation  phase; 
thus  the  contractor  snail  interact  with  the  government  to  generate  a  listing 
of  GFP,  as  appropriate.  The  listing  shall  ioentify  the  property  by  reference 
to  its  nomenclature,  specification  number  and/or  part  number  or  other 
appropriate  identification. 


3.12  Pre-Plannec  Proaiict  Ir^proverient 


Tne  I-S/P  mi-;PE  is  being  i.’ipleirentea  in  two  parallel  aim  inierlocrvea 
TrdC.-;s.  Trac.v  I  is  tne  r\.nctional  replacement  ana  ir.ple^ientaticn  of  valiaatco 
DaSc-levei  telcicoriiinunicatiuns  requirements,  anc  the  replacenent  or  certain 
AUTODIh  Switching  Center  functions.  Trac<  I  will  eniplay  trusted  computing 
base  (TC3)  tecnnolagy  in  the  design  aru  iir.pl  emeu  tat  icn  pnases  with  test  and 
evaluation  lT<i£)  to  tne  l'-Ij  level.  Rigorous  mathen.at i ca  1  great  aown  to  tne 
cuuing,  not  yet  state-of-the-art,  is  cererreo  tc  Trac<  II.  Tnus,  curing  Trac.< 
i  separate  lytoi-S  arc  b£.,ScR  syster.s  will  .^e  cepioyea.  .  le  l.SuwS  systems  ..ill 
accommoaate  CSSCS-cnly  ana  u'SSCS-al so-al  lov.eG-ta-pass-bEnSE.R  subscribers. 

Track  II  proviaes  tne  I-S/A  /ki-.PE  interrace(s)  to  the  Defense  Data  hetwerk 
(DDi\),  otner  as  yet  unvaliaatea  ennancenients,  ana  the  TCB  TivE  to  allow  full 
cansolioation  of  DSSCS  and  GENSER  facilities.  Track  II  efforts  will  be 
accompl isheo  by  pre-planneo  product  improvement  (P^I)  techniques. 

Pre-plannea  product  improvements  are  life  cycle  techniques  ta  proviae  features 
which  are  not  presently  inclucea  in  Track  I  (based  on,  e.g.,  lack  of 
tecnnolagy,  i.Tmediate  mission  need,  and  excessive  risx). 

3.12.1  Pre-Planneu  Product  Improveir.ent  Imp leirentaticr. 

Since  telecommunication  researen  ana  aeveloprrent  is  ongoing,  the  need  to 
implement  P^I  features  ccula  come  at  any  point  curing  tne  I-S/A  AMPE  life 
cycle.  Consequently,  the  I-S/A  AMPE  aesign  shall  explicity  induce  a  means  of 
incorporating  new  capabilities  such  as  P^I.  Once  tne  technology  is 
state-of-the-art,  recomendations  for  im.p lementi ng  a  validated  feature  will  be 
assessed  based  on  cast,  schedule,  and  performance  impacts  the  contractor  shall 
proviae  during  the  Formal  Review  Process,  as  P^I  features  are  approved  and 
validatea,  they  will  be  incorporated  into  the  I-S/A  AMPE.  The  following 
paragrapns  outline  P^I  requirements. 

3.12.2  AGoitional  I -S/M  AMPE  Services 

Since  the  telecommunications  environment  is  constantly  evolving,  future 
I-S/A  mMPE  subscribers  will  recognize  and  document  the  neea  for  aaaitional 
services.  Far  planning  purposes,  it  is  estimated  that  several  services  will 
be  requirea  in  addition  to  the  Formal  Message  Service  (See  para  3.2.1)  with 
its  Message  Editing  and  Preparation  Service  (See  para  3.2.2).  The  following 
services  are  examples  of  those  which  may  be  required: 

a)  Informal  Message  Service  (IMS).  Informal  Message  Service  provides  two 
capabilities:  "interactive"  and  "mailbox".  Interactive  Informal  Message 
Service  implies  a  near  real  time  "electronic  note  pad"  capability  between  two 
users.  "Mailbox  Service"  implies  the  ability  to  defer  delivery  (analagous  to 
"overnight  telegrams").  Such  service  might  be  provided  without  the  rigor  of 
the  FMiS  (e.g.,  lesser  degrees  af  assurea  delivery,  traceability,  recovery). 

b)  Teleconference  Service  (TCS).  This  service  proviaes  capability  for 
groups  of  subscrioers  to  use  the  IAS  network  to  engage  in  interactive  group 
transactions.  That  is,  an  "electronic  blackboard"  might  be  established  at 
each  af  several  "conference"  locations  for  group  sized  briefings,  lectures, 
and  so  on. 


c)  Data  Ease  Transacticn  Service  (LETS).  This  service  proviaes 
saDscrioers  .vitn  tne  capability  to  generate,  mocify,  ana  retrieve  cata  froin 
tneir  own  :i'  otner  sooscrioer  data  bases  '.vorla  .vice. 

Tne  I-S/A  AXPE  design  snail  alloiv  for  the  aooiticn  of  valioateo  new 
services  ana  the  enhancement  of  existing  functions  and  services  throucnout  the 
service  life  of  the  s^^stein. 

3  .  .  0  Data  Path  fecwests 

Eacn  Suoscriber  or  service  requesting  "cata  patns"  tnrcugn  the  I-S/A 
shall  require  valioation  to  access  either  a  suoscriber  directly  connecteo  to 
tne  I-S/r>  nriPE,  or  a  service  provided  by  the  I-S/A  AliPE  le.g.,  Formal  ilessage 
Service).  The  types  or  services  ano  connections  that  a  user  or  service  is 
authorized  to  invoke  shall  oe  precefineo  (e.g.,  by  a  classmark  or  a  table)  and 
tne  I-S/A  nMPE  shall  verify  that  tne  subscriber  request  is  authorized  prior  to 
granting  access.  The  following  examples  illustrate  potential  applications  for 
data  patns. 

a)  Directly  Connected  Suoscrioer  to  Another  Directly  Connected  Subscriber. 
T.-,c  I-S/n  A'flFE  biidli  nave  tne  capaoility  to  allow  a  SuOscrioer  uirectiy 
connected  to  the  I-S/A  AFiPE  to  communicate  with  another  subscriber  who  is  also 
directly  connected  to  the  same  I-S/A  AMPE,  without  requiring  processing  by  the 
Fi'iS . 


b)  Directly  Connected  Subscriber  to  Network.  The  I-S/A  AMPE  shall  allow 
a  subscriber  directly  ccnnecteo  to  the  I-S/A  AFiPE  to  estaolish  a  connection  to 
the  network.  This  type  of  connection  will  provioe  access  to  such  services  as 
tiie  Informal  Fiessage  Service  ano  the  Teleconferencing  Service. 

c)  Remote  Subscriber  to  Local  Service  Connection.  The  I-S/A  AWPE  shall 
provide  trie  capaoility  for  a  terminal  Access  Controller  (TAG)  subscriber  (a 
subscriber  not  directly  connected  to  an  I-S/A  AMPE)  to  establish  a  connection, 
througn  the  network,  to  an  I-S/A  AMPE  for  local  service  (e.g.,  MEPS).  The 
connection  request  shall  be  subject  to  access  control  to  determine  whether  or 
not  the  TAG  subscriber  is  allowed  access  to  that  particular  service. 

3.12.4  Preamp le  Format 

The  I-S/A  AMPE  shall  have  the  capability  to  identify  and  accept  for 
processing  messages  in  Preamble  format.  Preamble  is  a  format  useo  by  Army 
data  processing  installations  in  lieu  of  JANAP-128  format  (See  Appendix  D  of 
the  I-S/A  AMPE  Interface  Control  Document). 

3.12.5  Routing  Table  Update 

The  I-S/A  AMPE  shall  be  capable  of  receiving  alternate  routing  table 
update  information  from  the  IAS  Monitoring  Genter.  The  receipt  of  this 
information  shall  include  safeguards  to  prevent  malicious  or  accidental 
modifications  of  the  routing  tables. 
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3.12.6  l'SSCS  ana  GEMSER  Consol  iaation 


uuring  Track  I  tne  state-or-the-art  in  providing  trusted  computing  base 
soTtware  restricts  security  to  tne  level  or  tne  DcD  Computer  Security 

Center's,  Trustee  Computer  System  Evaluaticn  Criteria;  thus  the  I-S/A  mAPE 
‘.vill  oe  aeployea  either  as  a  ^'lulti  level  Secure  ^i-lLS)  GEhSER  or  a  MLS  DSSCS 
facility,  cependent  on  operational  requirements .  It  is  not  manoatory  that  the 
I/S-A  nMPE  meet  the  criteria  of  Class  A2  as  this  class  is  currently  ccnsidereo 
oeyonu  the  state-of-the-art .  houever,  aspects  of  Class  A2  that  can  be 
accomplisneJ  shculc  ce  consicered  ~cr  inccrpcracicn  into  the  I-S/A  A.;  PE. 

^.\ote:  To  meet  Class  a  fori..al  analysis  of  tne  ccject  ccae  is  req^-irec  to 
prove  that  the  impleiiientation  software  rulrills  tne  requirement  of  tne 
security  mooel.  Also,  formal  inetnoos  of  verification  are  applied  to  the 
hardware  design.]  In  adoition  to  tne  security  T&E,  this  Track  II  effort  shall 
include  the  design,  implementation  and  installation  of  any  modification 
necessitated  by  the  security  T&E. 

3.13  Traininc 


Estaol i snnient  of  a  comprenensive  life-cycle  oriented  training  program 
siiall  parallel  development  of  the  I-S/A  AMPE.  Ihe  initial  training  increment 
shall  oe  completed  in  time  to  support  the  IOC  deployment  of  the  I-S/m  AMPE. 


a.o  QUmLITY  nSSURn.NCE  PROVISIQ.NS 


An  extensive  I-S/A  n.VPE  Test  and  Evaluation  prograiii  shall  be  conouctea  to 
insure  tne  acquireo  system  ;r,eets  its  cperational  requirements.  Review  ana 
testing  or  liie  software,  hardware,  ana  functional  operation  shall  he  performed 
continuously  througnout  tne  development  ana  implementation  phases.  This 
effort  shall  De  aiviaed  into  a  numoer  of  evolutionary  steps  as  prescribeo  in 
tne  following  paragraphs  ana  Section  3.4,  I-S/A  Hi-, PE  Security.  Tiie 
contractor's  proposal  snail  fully  descrioe  now  tne  mandatory  review  and 
testing  requir=!i.ents  oescritea  nerein  shall  oe  ret,  uptiriizcc,  ana  integrate^ 
into  management,  and  security  progranis. 


Tne  government  intends  to  nave  an  independent  verification  ana  validation 
effort  covering  the  full  life  cycle  of  the  program.  General  guidelines  are 
provided  in  the  following  publications  (See  Section  2.0)  reference  2.5c, 
MIL-STD-1521 ,  ana  'lAVELEX  IMST  5200.23.  The  contractor  shall  also  proauce  a 
Software  Quality  Assurance  Plan  in  accordance  with  PUL -STD- 1679  (see  3.6.2). 

4 . 1  Contractor  Conf iguration/uevelopment  Reviews 


Tne  contractor  shall  conauct  configuration  management  -meetings  ana  auaits 
throughout  the  contractual  period  and  provide  configuration  management  aata  to 
tne  Government.  The  configuration  management  program  for  software  ana 
software  relatea  equipment  functions  shall  ensure  that  when  the  software  is 
transitionea  for  Government  control,  the  records  ana  data  are  in  aetail, 
format,  ana  status  to  allow  Government  use  for  future  modification 
recommendations  such  as  reviews  and  approvals.  Formal  design  reviews  shall  be 
conouctea  oy  the  contractor  for  the  Government  as  an  integral  part  of  the 
software,  hardware,  and  security  design,  development  ana  test  phases.  Formal 
security  design  review  will  be  conducted  by  the  Government  during  design, 
development,  ana  testing  phases.  At  each  review,  the  contractor  shall  conauct 
a  system/software  walkthrougn  using,  as  a  baseline,  the  latest  approved 
revision  of  tne  computer  software  specification  ana  aesign  plan.  As  a 
minimum,  aesign  reviews  shall  be  conducteo  to  support  the  Government's  review 
of  major  design  data  (e.g.  software  specifications).  Further,  the  contractor 
shall  schedule  ana  conduct  management  progress/status  reviews  at  each  key 
aecision  point  during  the  design  development  and  testing  of  the  I-S/A  AMPE 
program.  The  contractor  shall  identify  proposed  scheduling,  location  ana 
special  requirements  of  the  above  meetings  and  reviews  in  his  proposal,  and 
wnere  appropriate,  in  planning  data  required  by  applicable  DD  Form  1423s.  In 
addition,  the  contractor  shall  support  requirements  for  unscheaulea  meetings 
called  for  by  either  the  Government  or  the  contractor  to  discuss  special 
problems  requiring  early  resolution.  Proposed  agenda  of  subjects  to  be 
covered  in  Government/contractor  reviews  and  meetings,  and  minutes  thereof, 
shall  be  provided. 

4.1.1  Configuration  Management 

Total  system  configuration  management  shall  be  employed  in  the  I-S/A  AffPE 
program.  Configuration  managemient  empnasis  shall  be  placed  on  the  developed 
software,  firmware  ,  and  any  specialized  hardware,  as  these  areas  have  the 
greatest  technical  and  security  accreditation  risks  (see  Section  3.4).  The 
functions  of  the  I-S/A  AMPE  configuration  management  are  to  identify,  control. 
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provir.e  status  acco^iitinu  ana  verify  tiie  software  conf iguration  .^s  it  is 
jeveiopec.  Tnis  ccni,otes  forii.al  lire  cycle  baseliiie  cefinition  and  control, 
-jr::ial  revi^f-.-.s  ai.a  a,.aits,  ana  formal  cnange  status  acccunting.  "ForrraT'  is 
jc’'‘iriec  in  t.'.is  case  as  cccu-rentec  ana  agrcta  to  oy  tne  orferor  and  toe 
Governii.ent . 


.1.1  Ccnf icuration  .'vanacer.ent  Baselines 


The  contractor  snail  procuce  a  Software  Conf  iguration  |■^an  aGt;.".e''.  t  Plan  in 

iC c 0 rc  cif i c 6  /f  i  u p G r  j Tg p ^  •  c . 


‘^.l.l.B  Engineering  Change  Proposals 

Engineering  Change  Proposals  tECPs)  shall  be  tne  only  means  by  which  the 
tunctional,  allocated,  or  procuct  baseline  may  be  changec.  ECPs  shall  be 
preparea  anc  processea  as  specif ieo  in  the  CCRL.  Each  ECP  shall  incluae  all 
necessary  specification  change  notice's  (SCMs)  to  correct/revise  all  oocuments, 
to  include  tne  system  performance  specirication  ana  the  FRC/ICD,  which  have 
been  incorporateo  into  tne  contract.  It  is  important  to  note  tnat  control  of 
each  baseline  ccr,t1n..es  throughout  the  lifp  ry-cle  nf  the  contract.  Ttius,  a 
cnange  late  in  the  implementation  effort  may  impact  the  entire  hierachy  of 
baselines  engencering  changes  to  corresponoing  oocuments. 

d.k!  Development  Teat  ana  Evaluation  i^bT&E) 


The  contractor  shall  perform  necessary  cevelopment  testing  on  all 
naroware  units  and  subsystems,  and  associated  software  of  the  I-S/A  AT, PE  in 
order  to;  validate  his  equipment  selection  ana  its  conciticn  upon  receipt 
from  vendors;  insure  this  oesign  and  security  features  meet  specifieo 
operational  performance;  verify  his  testing  procedures;  and  proviae  the 
Government  a  high  level  of  confidence  that  operations  testing  will  be 
accomplisheo  with  minimum  delays  and/or  retesting.  Test  plans  and  procedures 
supporting  contractor  development  testing  shall  be  provided  the  Government. 
Contractor  development  testing  may  be  conducted  in  the  contractor's  plant, 
subcontractor's  facility,  the  nardware/sof tware  test  facility  ano/or  other 
approveo  testing  area.  Development  testing  shall  include,  but  not  be  limited 
to,  any  testing  requiring  Government  approval.  The  Government  will  retain  the 
rignt  to  witness  All  contractor  testing;  however,  such  witness  shall  not 
constitute  Government  acceptance,  or  reduce  Government  formal  operational 
testing  requirements.  The  development  testing  cycle  shall  induce  complete 
integrateo  testing  of  all  hardware  units,  subsystems,  and  applicaole  software 
modules  prior  to  release  for  installation. 

A. 2.1  Software  Testing 


Comprehensive  and  integrative  testing  of  software  shall  be  performeo  by 
the  contractor  in  accoroance  with  ana  Sections  3.4  and  3.0  at  critical  points, 
as  defined  below,  in  development  of  the  system  software.  This  testing  shall 
be  conducteo  sequentially  as  software  modules  are  developeo,  followed  by 
integration  testing  of  functional  sets  of  mocules  with  final  hardware/software 
testing  of  all  modules  required  to  control  tne  complete  I-S/A  AXPE.  Software 
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testing  shall  ccnfonr.  to  ircoular  aevelcpmer.t  oroer  the  approved  str-jctorec 
prograiiimi nq  iiieinous.  Tne  GoverniTient  shall  be  invited  to  witness  anc/or 
participate  in  all  contractor  software  testing.  Scft>vare  testing  ana  tne 
reporting  and  approval  of  test  reSo.lts  shall  oe  acccmplishco.  Tne  contractor 
snail  insLii'c  tnat  specific  ano  cetaileo  testing  of  security  nouule's;  is 
accomp 1 i Shea .  Software  ano  software  security  testing,  described  Iwarein,  shall 
be  cornpletea  ano  approveo  prior  to  the  start  of  the  operational  testing 
specified  in  4.3. 

Soft.vare  test  plans  anc  procecures  snail  be  prepareo  by  the  contractor  in 
acc>.raar,ce  witn  i-iIb-STD- lo79  ana  Section  3.4  ana  suPinitted  to  tne  Gover,n:;.er: t 
for  approval.  Furtner,  software  testing  shall  oe  uefineo  in  the  Test  Program 
Outline/Plan  requireo  by  4.4.  These  plans  shall  provioe  for  the  levels  of 
testing  described  herein;  separate  test  procecures  shall  be  provided,  as 
necessary,  to  support  indivioual  module  ano  integrative  testing. 

Tnis  testing  shall  use  a  builoino  block  approacti  with  full  testing  at 
eacn  iteration.  First,  tne  individual  software  modules  shall  be  testeo. 

Tnen,  these  tested  mooules  shall  be  integrateo  on  a  functicnal  basis  ano 
testeo.  Finally,  the  complete  software  program  for  tne  I-S/A  mFiPE  snail  be 
integrateo  with  associateo  haroware  ano  fully  testeo. 

4.2.2  Electromagnetic  Testing  Requirements 

The  I-S/A  AFiPE  shall  be  tested  to  demonstrate  full  compliance  with  the 
requirements  of  the  ICD. 

4.3  System  Testing 

System  testing  for  the  I-S/A  AMPE  system  shall  induce  site  testing  in  at 
least  one  mutually  selected  location.  Altncugh  systems  software/hardware  may 
oe  testeo  at  the  mooule,  unit,  subsystem  or  even  site  level  in  the  various 
pnases  of  testing  prior  to  system  ana  Government  testing,  successful 
completion  of  preliminary  testing  will  constitute  conditional  acceptance  only 
(for  contract  milestone  purposes).  Final  system  acceptance  will  be  subject 
to;  tne  successful  completion  of  all  system  testing  ano  Government  conducted 
operations  testing,  and  the  approval  of  test  results  by  the  Government. 

4.3.1  Site  Acceptance  Testing 

Site  testing  shall  be  designed  and  concucted  in  accoroance  with  Sections 
3.6  and  3.4.  Formal  testing  shall  be  conoucteo  unoer  the  direction  of  a 
Government  provioed  test  director  at  each  site.  During  site  testing,  each 
site  shall  be  inoividually  tested.  This  testing  will  be  considered  the 
initial  phase  of  acceptance  testing  ano  shall  include  all  haroware/software  in 
its  final  design  configuration  unless  specifically  waived  by  the  Government 
Test  Director. 
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T'n's  tesciiig  snail  veriry  that;  tne  installation  and  racility  perfcrmance 
xeecs  all  reqdiren.ents  or  the  specir  i  catioivcoturact  except  those  requiring 
ccr'oleta  !et.-.crs  intecracicn  (as  required  ror  systein  testing  in  -.3.2);  tlie 
site  naru'..  are/Su*  t.-.are  is  properly  ir.’terc>,r.nectc.;  ano  cceratior.al  ly  ccK.patiule 
.-.itn  connecteo  GFE,  itul  tiplexers,  ana  suoscriber  ".'Ceer  s/ ‘  nterf  ace  cq^i  pi.sents , 
as  appropriate;  tne  site  meets  all  requirements  rcr  interface,  formats  ana 
cooes;  proper  operational  techniques  have  oeen  cevelopeo  for  processing 
trafric  under  normal  ano  stressed  concitiens;  perfurr ance  requ i ren'ents  are  met 
-n>-.er  ootn  '■ijr''  al  anu  stressed  ccnciticns,  and  tne  req..  < r'eme;  ts  of  scrt'.vcre 

ScCc^'ily  I.c;SIl1nO  3^0  in0 1  .  I  6S  t  i  n  m  ^  b  L.DSC  r  '  3  cT  i  t  (  3  ePT  3C0  '"i  Brev,  0  all  0 

software  snail  include  :  1 1  operaticnal  con  patio  i  h  tj/  anc  security  testing  of 
all  access  area  cemponents.  Site  testing  snail  oe  ccnouctec  in  accordance 
.-jitn  tne  contractor  provioeo.  Government  approvec  Installation  ana  C.heCKOut 
Test  Plan  and  Proceaures.  Sufficient  equipment  for  each  site  testing 
terminals,  traffic  generators,  network  simulators  shall  be  provideo  by  the 
contractor  so  tnat  all  operational  requirements  can  be  fully  testeo. 

-+.3.2  System  Tests 

UDcn  successful  completion  or  an  initial  ofr-line  system  test,  the  I-S/n 
Mi-;PEs  shall  Oe  connecteo  to  Ootn  the  mUTOOIT;,  DDM,  TRI-TnC  Equipiiient,  anc 
blCS/TARE  in  preparation  for  full  system  testing.  Successful  performance  of 
this  system  test  ano  Government  testing  specifieo  in  4.3.3  ana  Section  3.4 
must  be  oemiOnstratea  prior  to  furtner  installation  of  fcllcw-on  I-S/A  AMPEs. 
The  follow-on  units  shall  be  integrateo,  testea  ana  acceptea  on  a  site-by-site 
oasis.  The  system  test  shall  consist  of  sequences  of  events  to  exercise  and 
test  all  areas  of  system  software,  and  verify  that  tne  I-S/A  AMPE  hardware  ano 
software  meets  the  total  requirements  of  the  specification/contract.  The  test 
shall  oemonstrate  that  the  I-S/A  AMPE,  operating  witn  AUTODIN,  DON,  TRI-TAC 
Equipment,  and  NICS/TARE  provides  message  integrity  ana  protection  with 
reliable  security  provisions  unoer  all  operating  conditions  while  at  the  same 
time  meeting  traffic,  speed,  throughput,  reliability  ano  availability 
requirements.  The  interconnection  of  different  user  types  shall  be 
specifically  tested.  All  users  operating  with  standard  protocols  and 
interfaces  as  well  as  users  operating  with  unique  link  protocols  (See  ICO 
4.2.2)  or  variations  to  FriS  (See  paragraph  3.2.1)  snail  be  testea  to  insure 
that;  (1)  all  user  types  can  exchange  message  traffic  through  FMS;  ana  (2) 
all  local  user  types  who  have  the  capability  to  select  connection  to  other 
local  users  shall  be  able  to  intercommunicate  with  each  other.  System  testing 
shall  be  conducted  by  the  contractor  under  the  airection  of  a  Government  test 
director  in  accordance  with  contractor  proviaea/Government  approved  System 
Implementation  Test  Plan  and  Procedures. 


As  a  final  pnase  of  system  testing,  the  Government  will  conouct  formal 
testing  of  the  I-S/A  AMPE.  The  Government  will  prepare  all  necessary  test 
plans  and  procedures,  test  configuration  and  test  data,  and  provide  for 
aocumentation  and  analysis  of  test  results.  The  contractor  shall  not  have 
access  to  tnese  test  plans,  procedures,  test  configuration,  or  test  data  prior 
to  Government  testing.  This  Government  testing  will  include,  out  not  be 
limitec  to,  operational,  performance,  and  security  testing.  The 
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ccntractor  shall  support  this  effort  to  the  sane  exnent  as  requirea  for  one 
sj/steif  testing  oiscusseo  in  paragrapn  4.3.2.  Sufficient  time  and  resources  to 
support  tnis  testir.q  snail  be  icentifiea  in  tne  contractor's  proposal.  Tne 
3c'.  e‘'r-e'it  vi’l  nave  a  ninimoT,  of  9U  un interruptec  testing  caps  in  order  to 
perfc'":  tnis  lescing.  The  term  "unintcrruptea  nesting  daps"  is  cefineo  as  tne 
time  period  coring  v.nich  there  are  no  nutstanoing  (open)  deficiencp  repor'is. 
Snculd  oeficicncp  reports  oevelop,  the  testing  time  period  will  be  restarted. 

a.u  lest  Jcc ^I'.en t a t i on 

Tne  contractor  snail  prepare  oetailea  test  plans  and  procecures  in 
accor'oance  .viin  Sections  3.4  ana  3.6  to  insure  all  contractor  conouctea 
testing,  outlineo  above,  will  be  accomplisheo.  The  contractor  shall  provide 
test  results  to  the  Government  for  all  tests  ana  evaluations  performed  as 
required  (See  3.6.2). 

4.4.1  Test  Prodram  Outl ine/^lan 


An  overall  Test  Program  Outline  and  Plan  integrating  all  phases  of 
testing  shall  oe  prepared  ana  suomittea  to  the  Government  for  approval.  Tne 
lest  Program  Outl  ine/Plcir;  snail  cescrioe  one  oeg inn  inu-tu-eiid  testing  concept, 
phasing  ana  integration  of  testing,  test  oojectives,  planning  factors  ana 
sciieculing,  facilities  required,  cescription  of  inaiviaual  tests  ana  basis  for 
acceptance  ror  all  contractor  testing. 

4.4.2  Test  Plans  ana  Procedures 


Test  Plans  ana  Procedures  shall  be  prepared  by  the  contractor  to  detail 
resources  ana  assets  required,  test  requirements,  test  data,  procedures,  test 
limits,  layouts,  ana  acceptance/rejection  ana  retesting  criteria  of  all 
aevelopment  and  operational  testing.  Theta  shall  be  prepared  ror  unit, 
subunit,  ana  subsystem  level  testing;  for  site  testing;  for  overall  I-S/A  AfiPE 
system  testing;  and  for  the  special  testing  requirements  of  TEMPEST  ana 
EMI/EMC.  These  test  plans  and  procedures  shall  provide  for  adequate  testing 
of  system  aesign,  hardware  and  software,  system  security,  and  installation. 

4 . 5  Responsibilities  for  Contractor  Conducted  Testing 

4.5.1  Contractor  Test  Procedures 


Once  the  development  test  plans  and  procedures  have  been  accepted  by  the 
Government,  the  contractor  is  responsible  for  implementing  and  documenting  the 
tests  and  inspections  as  necessary  to  demonstrate  acceptable  performance.  The 
contractor  sha  1 1 ; 

a.  Prepare  and  forwara  to  the  Government  for  approval  an  overall 
system  test  program  outline  ana  plan,  functional  area  test  plans  ana 
procedures,  and  acceptance  test  plans  and  procedures. 

b.  Inform  the  Government  (Test  Director)  in  writing  at  least  30 
days  prior  to  desired  start  date  of  any  testing  wnich  is  subject  to  Governm.ent 
witness  or  approval. 
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c.  Conduct  validation,  functional  and  acceptanca  testing  and 
supcort  covernxent  security-  testing,  as  required  in  test  plans  ana  procedures. 

a.  Cocutient  test  results  in  coordinaticn  with  the  Govern.T,ent  Test 

Director . 

e.  Maintain  complete  records  of  inspections  and  test  results  for 
review  by  Government  represents  tives  and  submit  test  reports  to  the  Government 

g.5.2  Government  Responsibilities 

The  Government  will: 

a.  Review  and  accept,  provide  recommended  changes,  or  reject  test 
plans  and  procedures  submitted  by  the  contractor. 

b.  Be  prepared  to  witness/conduct  testing  within  30  days  after 
receipt  of  written  notification  from  the  contractor. 

c.  Direct  and  participate  in  formal  acceptance  testing  in 
accordance  with  approved  test  plans  and  procedures,  and  with  the  support  of 
the  contractor. 

d.  Provide  acceptance  or  rejection  of  test(s)  results  within  time 
fra.mes  specified  in  DD  Form  1423. 

4 . 6  Equipment 

The  contractor  shall  furnish  all  equipment,  services,  and  facilities 
required  for  testing  except  Government  Furnished  Cryptographic  Equipment  and 
Subscriber  terminals.  The  contractor  shall  furnish  transmission  facilities  to 
existing  ASCS  and  PSNs,  and  to  any  subscriber  terminals  which  may  be  utilized 
during  the  testing  at  the  test  facility.  The  contractor  shall  submit,  subject 
to  Government  acceptance  and  amendment,  t,he  subscriber  configuration  necessary 
to  meet  the  test  requirements  as  part  of  testing  prescribed  in  4.3.1  and  4.3.2 

4 . 7  Quality  Assurance  Provisions  -  Security  Design 

Security  requirements  are  described  in  Section  3.4,  I-S/A  A.MPE  Security. 
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^0.0  DtFIMITIONS  AHD  TERMiriOLOGY 


TERM 

AC:<  (AC:<.'iOWLEDG‘-'EN^): 


Access  Control : 


ACM  (Access  Control 
Meehan i sn) : 

Altroute  (Alternative 
Routi  ng) : 


Af’IPE  (Autonated  Message 
Processing  Exchange); 


ASC  (AUTODIM  Switching 
Center): 


AUTODIN  (Automatic  Digital 
Netv/ork )  ; 


A  control  sequence  sent  either  to  or  from  the 
subscri ber . 

Actions  taken  to  permit  or  deny  use  of  the 
components  of  a  communications  system.  (MCS) 

A  hard\/are  and/or  software  component  that 
implements  an  object  protection  strateg:/. 

A  process  whereby  alternate  delivery  stations  are 
used  when  circuit  failures,  equipment  outages,  or 
backlogs  develop  which  restrict  delivery  to 
primary  addressees. 

Equipment  which  automates  the  functions 
necessary  to  transmit,  receive,  and  process 
messages  to  and  from  or  within  a 
telecommunications  network.  AMPEs  may  stand 
alone  ot'  provide  service  to  remote  terminals. 

The  switch  node  in  AUTODIN  that  performs 
the  store-and-forv/ard  message  functions  and 
includes  the  patch  and  test  facility,  power 
generation  and  distribution,  modems, 
cryptographic  equipment,  and  other  peripheral  or 
support  functions. 

Note:  The  leased  and  government-owned  AUTODIN 
switching  centers  are  operationally  compatible, 
although  they  differ  in  capabilities,  hardware, 
and  software.  They  function  as  a  common  system 
and  will  be  referred  to  by  the  common  term 
"ASC.  The  prefix  "Leased"  or  "Government-owned" 
ASC  is  used  when  addressing  or  emphasizing  a 
peculiar  function  of  only  one  type  of  ASC. 

The  Automatic  Digital  Network  (AUTODIN) 
is  a  switched  netv/ork  of  the  Defense 
Communications  System  (DCS),  which  functions  as  a 
single,  integrated,  worldwide,  high-speed, 
computer-control  1 ed ,  general -purpose , 
store-and-forward  communication  network, 
providing  record  communications  service  to  the 
Department  of  Defense  (DoD)  and  other  Federal 
Government  Agencies.  It  consists  of  all  AUTODIN 
Switching  Centers  (ASCs),  interswitch  trunks,  and 
all  subscriber  stations  connected  thereto.  This 
secure,  fully  automatic,  switching  network  was 


designed,  engineered,  and  programned  to  provide 
continuous  operation,  niniiaal  loss  of  service, 
and  no  loss  of  traffic;  and  has  done  so  since 
1  964. 

Blacker  Progran  An  end-to-end  encryption  progran  v/ith 

applicability  to  the  I-S/A  AMPE's  connection  to 
the  Defense  data  Network  (DDN). 

A  three-digit  number  used  to  indicate  the 
sequential  number  of  the  transmission  on  a 
channel  betv/een  two  stations.  These  nur.bers 
shall  commence  with  number  001  and  continue 
consecutively  through  000  (lOOD). 


CARP  (Contingency  Inherent  in  all  ASCs  is  a  program  identified 

Alternate  Routing  Program);  as  the  Contingency  Alternate  Routing  Program 

(CARP).  This  program  provides  an  automatic 
capability  of  routing  a  message  destined  for  an 
identified  station  to  an  alternate  station  not 
necessarily  connected  to  the  same  ASC.  CARP  can 
be  used  to  dllevidLe  bdcklogs,  for  traffic 
management,  or  during  a  contingency  condition, 
e.g.,  ASC  failure.  CARP  cannot  be  applied  to 
messages  routed  by  a  collective  routing  indicator. 

Classification:  The  security  classification  of  the  message. 

Classmark;  Designators  used  to  describe  the  service 

privileges  and  restrictions  for  lines  accessing  a 
switch,  e.g.,  precedence  level,  security  level, 
zone  restriction. 

Content  Indicator  Code:  The  Content  Indicator  Code/Communication  Action 

Identifier  (CIC)  is  composed  of  four  alphabetic 
or  three  alphabetic  and  one  numeric  character  in 
format  line  two  of  a  message  which  can  be  used  to 
specify  the  content  of  the  message.  See 
JANAP-128  ANNEX  B. 

The  highest  precedence  message  processed  by  the 
DSSCS.  Critic  messages  in  the  DSSCS  community 
are  recognized  by  the  Critic  prosign  of  "'./V/ 
YEKAAH".  CRITIC  messages  are  provided  special 
handling  in  the  AUTODIN  system  and  require 
special  operating  procedures  to  ensure  proper 
delivery.  CRITIC  messages  preempt  messages  of 
any  other  precedence  with  the  exception  of  ECP 
messages  or  another  CRITIC  message. 

Defense  Communications  Agency  Circular 


CRITIC: 


DC  AC: 


CSN  (Channel  Sequence 
Number ) : 
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DDM: 


Defense  Data  Network,  packet  switching  backbone 
for  the  Integrated  AdTODIN  Systen. 


DSSCS; 


Duplex: 


EAM  (Emergency  Action 
Ilessage) : 


ECP  (Emergency  Command 
Precedence); 


e3 

EOM: 

Far-Term: 

FIFO  (First-In-First-Out): 

FMS  (Formal  Message 
Service) : 


Defense  Special  Security  Communications  System, 
DSSCS  is  the  intelligence  community  record 
message  portion  of  the  AUTODIM. 

A  communication  system  or  equipment  that  can 
carry  information  in  both  directions  between  tv/o 
points.  See  Full-Duplex  and  Half-Duplex. 

High  precedence  message  that  is  transmitted 
at  Emergency  Command  Precedence  or  Flash 
Precedence.  An  EAM  of  flash  precedence  with  the 
appropriate  CIC  is  queued  to  the  front  of  the 
GENSER  flash  queue,  but  not  ahead  of  a  DSSCS 
flash  message. 

Emergency  Command  Precedence  is  designated 
for  use  on  certain  time-sensitive  command  and 
control  emergency  action  messages.  ECP  preempts 
all  messages  of  lower  precedence.  Only  the 
National  Command  Authority  (NCA)  and  certain 
designated  commanders  of  Unified  and  Specified 
Commands  are  authorized  to  use  the  ECP  capability 
of  the  AUTODIN  system  and  then  only  for  certain 
designated  emergency  action  command  and  control 
messages.  ECP  is  the  highest  precedence  in  the 
GENSER  community. 

End-to-End  Encryption 

End  of  Message 

The  time  frame  after  phase  out  of  all  of  the  ASCs. 

The  system  where  incoming  messages  are  processed 
sequentially  and  transmitted  at  the  end  of  their 
respective  precedence  queue  when  completely 
received. 

FMS  provides  the  capabilities  for  IAS 
subscribers  to  create,  send,  and  receive  formal 
messages.  Formal  message  service  can  be 
regarded,  in  large  part,  to  be  a  continuation  of 
AUTODIN  "official"  message  service.  Formal 
messages  are  defined  as  messages  that  are 
prepared,  handled,  released,  and  recorded  for 
storage  in  accordance  with  Service/Agency 
procedures. 
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FRD  (Functional 
Requi rements 
Descri pti on ) ; 

Ful  1  -Duplex  Channel  : 

Full-Duplex  Transmission; 

Functional  Requirements: 

GENSER  (General  Service) 
Traffic: 

Guard: 

Hal  f-Duplex  Channel  : 
Half-Duplex  Transmission: 

History  File: 


History  Search  Capability: 


Describes  and  baselines  the  functiona' 

'requirements  for  the  Inter-Se'^vi ce/Agency 
Automated  Message  Processing  Exchange  (I-S/A 
AMPE).  This  document  provides  a  definitive 
description  of  the  needs  of  the  participating 
riilitary  Services  and  Defense  Agencies,  and  the 
Defense  Communications  Agency  (DCA). 

A  communications  channel  './here  the  signals  may 
flow  in  both  directions  simultaneously  and 
independently.  The  signaling  speeds  used  for  the 
two  directions  of  transmission  on  a  ^ull -duplex 
channel  need  not  be  the  same. 

A  type  of  transmission  where  information  is  sent 
in  both  directions  simultaneously  and 
independently.  Tv/o-way  simultaneous  transmission. 

Functional  requirements  are  the  actions  needed  to 
perform  the  Service/Agency  mission,  and  the 
quantitative  performance  parameters  needed  to 
specify  the  extent  of  the  action. 

Traffic  that  includes  all  security 
classifications,  excluding  DSSCS  traffic. 

The  telecommunications  center  provides  internal 
office  distribution  to  specified  organizations. 

A  circuit  that  affords  communication  in  either 
direction  but  only  in  one  direction  at  a  time. 

A  type  of  transmission  where  information  is  sent 
in  one  direction  or  the  other,  but  not  both 
directions  simultaneously. 

A  complete,  continuously  maintained 
communications  record  to  include  the  following 
information  for  each  message  processed  by  the 
AMPE:  A  complete  copy  of  the  message  as  received 
(with  the  exception  of  ALPS  and  SDS  messages 
whose  text  shall  not  be  recorded);  a  complete 
record  of  all  message  transactions  beginning  with 
the  start  of  the  message  into  the  I-S/A  AMPE  and 
ending  with  receipt  of  the  end  of  message 
acknowledgement  from  the  last  addressee  terminal. 

The  capability  to  search  history  files  (on-line 
or  off-line)  based  on  varied  criteria  to  extract 
message  data  for  display  or  print. 
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Host; 


lASA: 

IAS  Metev/ork 


ICD  (Interface  Control 
Docunent) : 

Intercept  Processing: 


Interface: 


Interface  Criteria: 


An  IAS  Host  is  a  piece  of  user  equipment  that  is 
connected  to  the  IAS  backbone  (the  DD‘J)  and  is 
capable  of  handling  s'mul  taneously  multiple 
logical  channels  with  the  IAS. 

"he  Integrated  AUTGDIIl  System  (IAS)  is  the 
narrative  record/data  portion  of  the  Defense 
Communications  System.  The  IAS  will  evolve  from 
the  currently  operational  AUTODIfJ 
store -and- forward  message  switching  netvrork  and 
the  packet-sv/i  tching  Defense  Data  Network.  The 
principal  concept  is  that  DDM  will  be  the 
communications  backbone  and  along  with  the  I-S/A 
AfiPE  v/ill  provide  the  communications  connectivity 
for  all  users. 

IAS  Architecture,  see  lASA  Report  (Part  3). 

The  I-S/A  AilPEs  and  their  connectivity  to  other 
I-S/A  Af'IPEs.  Initially  for  the  I-S/A  AfiPE,  the 
connection  is  through  AUTODIN, then,  as  I-S/A  AMPE 
deployment  progresses,  a  combination  of  AUTODIN 
and  DDN.  Finally,  as  AUTODIN  is  phased  out,  it 
will  be  through  DDN  only. 

Interface  Control  Document(s)  serve  as  the 
repository  for  environmental,  mechanical, 
electrical,  protocol /format,  and  human  interface 
criteria  controlling  or  constraining  the 
functional  requirements  described  in  the  FRD. 

Intercept  processing  provides  operator  initiated 
interim  storage  for  messages  whose  delivery  is 
delayed  by  an  inoperative  or  backlogged  output 
channel.  Using  intercept,  the  AMPE  can 
temporarily  hold  messages  for  a  destination  which 
is  partially  or  completely  out  of  service  or 
which  operates  on  a  part-time  basis. 

A  boundary  or  point  common  to  two  or  more  systems 
or  other  entities  across  which  useful  information 
flow  takes  place.  (It  is  implied  that  useful 
information  flow  requires  the  specification  of 
the  interconnection  of  the  systems  which  enables 
them  to  interoperate.) 

Interface  criteria  are  the  functional/  physical 
characteristics  required  to  exist  at  boundaries 
between  tv/o  or  more  equipments  or  computer 
programs  provided  by  different  DCS  or 
Service/Agency  subsystems  or  contracted 
{tariff/leased)  subsystems. 
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Interoperabil i ty : 


i  • 
^  • 
► 


I 


In-transit  Storage: 


IOC  (Initial  Operating 
Capabi 1 i ty) : 


The  ability  of  systems,  units  or  forces  to 
provide  services  to  and  accept  services  from 
other  systems,  units  or  forces  and  to  use  the 
service  so  exchanged  to  enable  them  to  operate 
effectively  together. 

In  a  store  and  for'./ard  message  processing  system, 
storage  that  is  used  to  store  messages  that  have 
been  acknowledged  on  input  but  have  not  been 
delivered  to  all  addressees  on  input,  i.e., 
messages  occupying  intransit  storage  space  are 
those  currently  undergoing  input  or  output 
processing  or  currently  on  queue  for  output 
delivery.  Messages  on  intercept  or  overflow 
storage  do  not  occupy  in-transit  storage  space. 

The  first  attainment  of  the  capability  to 
employ  effectively  a  weapon,  item  of  equipment, 
or  system  of  approved  specific  characteristics, 
and  which  is  manned  or  operated  by  an  adequately 
trained,  equiped,  and  supported  military  unit  or 
force. 


I-S/A  AMPE  (Inter-Service/  The  standard  element  that  will  replace  the 
Agency  Automated  Message  individual  message  processing  exchanges  of 
Processing  Exchange:  the  Services  and  Agencies  and  the  ASCs. 


LA: 


Logical  address,  binary  address  of  host 
subscriber  to  the  DDN. 


Language  Media  Format: 


Loopi ng: 


Message: 


Language  Media  Format  (LMF)  is  a  single 
alphabetic  character  which  describes  message 
media  and  format,  LMFs  are  used  in  pairs  to 
indicate  the  source  and  preferred  destination 
media  format.  NOTE:  For  more  detail,  see  JANAP 
1 28,  paragraph  414. 

A  message  passing  through  the  same  I-S/A  AMPE 
more  than  one  time  before  delivery  to  its  final 
desti  nation. 

Any  thought  or  idea  expressed  briefly  in  a  plain 
or  secret  language,  prepared  in  a  form  suitable 
for  transmission  by  any  means  of  communication. 
(JCSI) 


Message  Accountability:  A  process  utilizing  a  unique  series  of  numbers 

used  to  ensure  the  known  disposition  of  every 
message  and  to  provide  the  bookkeeping  associated 
with  message  handling. 

Message  Editing  and  See  paragraph  3.2.2 

Preparation  Service 

[MEPS] 
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■lessage  Recovery: 


i‘'essage  Retransm  ss  ion : 


Message  Retrieval: 


'lessage  Switching: 


Mid-Tern: 


Misrouted  flessage: 


Mis sent  Message: 


Modular: 


The  ability  to  recover  and  protect  delivery  for 
messages  that  have  been  acknowledged  on  input  but 
not  delivered  on  output  and  have  been  temporarily 
lost  due  to  AjMPE  equipment  (processor  or 
peripheral),  soft'./are  or  total  system  failu'^e. 

Retransmitting  of  a  message  or  group  of  messages 
that  have  previously  been  transmitted  and  receipt 
acknowledged  by  the  addressee (s ) .  Message 
retransmissions  are  normally  performed  at  the 
request  of  the  addressee(s) .  Messages  to  be 
retransmitted  must  be  retrieved  from  AMRE  history 
files  and  each  retransmission  shall  be  marked  ZDK. 

The  ability  to  retrieve  a  previously  delivered 
message  or  group  of  messages  from  history  files 
(on-line  or  off-line)  based  on  varied  criteria 
for  print,  display  or  retransmission  purposes. 

The  technique  of  receiving  a  message,  storing  it 
until  the  proper  outgoing  line  is  available,  then 
transmitting.  Mo  direct  connection  between  the 
incoming  and  outgoing  lines  is  set  up  as  in 
circuit  switching. 

The  time  frame  which  includes  the  fielding  of  the 
I-S/A  AMPE  and  concludes  with  the  phasing  out  of 
all  ASCs. 

A  misrouted  message  is  one  which  contains  an 
incorrect  routing  instruction. 

A  missent  message  is  one  bearing  a  correct 
routing  indicator  but  transmitted  to  a  station 
other  than  the  one  represented  by  the  routing 
indicator.  Altrouted  messages  contain  the  RI  of 
the  delivery  station  in  Format  Line  2  and  are  not 
in  this  category. 

a.  Software. 

The  goal  of  modular  design  is  to  build 
independent  functional  pieces  of  a  computer 
program  which  can  be  separately  developed, 
tested,  and  modified  or  replaced.  Good  modular 
design  minimizes  and  allows  easy  modification. 
Software  which  employs  modules  must  rely  only  on 
a  limited,  well  defined  set  of  properties  for  the 
modules.  Nothing  in  the  software  should  depend 
on  the  internal  method  by  which  the  modules 
accomplish  their  job.  Proper  modularity  will 
reduce  code  by  collecting  similar  functions  into 
one  module.  It  increases  the  program's  clarity 
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by  enploying  a  snail  conceptual  set  of  well 
defined  properties  to  construct  larger  progran 
el  enents. 

b.  Hardware. 

(1)  A  degree  of  standardization  of 
conputer/connunications  systen  conponents  to 
allow  for  conbinations  and  large  variety  of 
conpatible  units. 

(2)  The  deterni nation  of  the  design  of  the 
equipment  such  that  conponents  can  be  readily 
identified,  altered,  or  augmented  without 
replacements  of  particular  units  or  sections. 

Monitoring  Center  Function  This  function  is  to  provide  an  automation 

assisted  capability  to  maintain  a  current  status 
as  to  the  efficient  operation  of  the  I-S/A  AMPE 
sub-netv/ork.  The  HC  function  is  to  be 
implemented  on  a  regional  basis  (CONUS,  Pacific, 
Europe)  that  will  be  collocated  with  major  DCS 
systems  operations  centers  and  will  support 
individual  I-S/A  AMPE  status  reporting  as  well  as 
sub-netv/ork  level. 

Near-Term:  A  point  in  time  prior  to  fielding  of  the  I-S/A 

AMPE. 

Network:  An  organization  of  stations  capable  of 

intercommunication  but  not  necessarily  on  the 
same  channel . 

The  NICS  TARE  System  is  an  automatic 
store-and-forward  message  relay  system. 

The  automatic  switching  centers  are 
interconnected  with  dedicated  trunk  circuits. 

They  serve  users  via  dedicated  low  speed 
(typically  50/75  baud  telegraph)  and  medium  speed 
subscriber  circuits.  The  TARE  Network  will 
accept,  process  and  retransmit  messages  in  the 
formats  specified  in  ACP  127,  NATO  Supplement  3, 
as  well  as  in  the  basic  ACP  127  (manual  torn-tape 
relay)  formats.  No  other  formats  will  be 
accepted.  The  NATO  versions  of  ACP  127  are 
somewhat  different  from  those  used  in  the  AUTODIN. 

NSA:  National  Security  Agency 

Off-Line:  That  condition  wherein  devices  or  subsystems  are 

not  connected  into,  do  not  form  a  part  of,  and 
are  not  suject  to  the  same  controls  as  an 
operational  system.  These  devices  may,  however, 
be  operated  independently. 


NICS/TARE  (NATO  Integrated 
Communications  System/ 
Telegraph  Automatic  Relay 
Equi pment) : 


On-L’ net 


Ope'^ating  Signal; 


OSRI  (Originating 
touting  Indicator) 

OSSN  (Originating 
Serial  Munber): 


Overflov/  (Channel) 


Overflow  (Input): 


Overflow  (System); 


That  condition  wherein  devices  or  subsystems  are 
connected  into  and  form  a  part  of,  and  are 
subject  to  the  sane  controls  as,  an  operational 
system. 


An  operating  signal  consists  of  three  alphabet"-; 
characters  and  a  fourth  position  for  a  numeric  or 
blank  — used  to  convey  message  handling 
instructions,  see  ACP  131. 

Station  The  routing  indicator  of  the  station  that 

:  originated  a  message. 

Station  a.  Station  Serial  lumbers  are  used  for  two 
purposes:  (1)  in  combination  with  the 
originating  station's  routing  indicator  they 
provide  positive  identification  for  each 
transmission,  and  (2)  as  the  EOM  validation 
number  appearing  in  format  line  15  they  provide  a 
means  by  which  ASCs  check  for  the  existence  of 
straggler  messages. 

b.  The  OSSM  is  expressed  in  four  numeric 
characters  beginning  with  0001  and  continuing 
consecutively  through  9999  .  On  completion  of 
each  series  of  numbers,  a  new  series  begins. 

:  This  function  is  similar  to  system  overflow 

except  it  is  output  channel  oriented,  e.g.,  when 
the  specified  traffic  queue  threshold  for  a  given 
output  channel  is  reached,  the  most  recently 
received  and  lowest  precedence  messages  destined 
for  that  channel  are  diverted  to  overflow 
storage.  This  function  is  also  system  controlled. 

The  purpose  of  this  system  controlled  function  is 
to  return  messages,  previously  placed  on  overflow 
storage  due  to  system  or  channel  overflow 
conditions,  to  the  output  channel  queue  when 
system  and/or  channel  thresholds  indicate  that 
such  action  is  warranted.  The  messages  are 
returned  to  the  output  queue  in  such  a  manner 
that  FIFO  by  precedence  is  maintained. 

lihen  a  specified  threshold  of  system  traffic  has 
been  reached  indicating  that  the  system 
in-transit  storage  capacity  is  near  saturation, 
candidate  messages  are  diverted  to  overflow 
storage.  Candidate  messages  for  overflow  are 
determined  by  precedence,  time  in  the  system, 
queue  load  and  channel  activity.  In  general,  the 
most  recently  received  and  lowest  precedence 
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Plain  Language  Address 
(PLA)  Directory: 


Plain  Language  Address 
(PLA)  to  Routing  Indicator 
(RI)  Assignment: 

Precedence: 


messages  destined  for  inoperative  or  backlogged 
channels  are  diverted  to  overflow  storage.  This 
function  is  system  controlled. 

Plain  Language  Address,  an  abbreviated  or 
complete  activity  (organizational)  title.  The 
geographic  location  may  or  may  not  be  included 
with  the  title. 

A  directory  consisting  of  a  compilation  of 

Plain  Languaae  Addresses.  (Often  refered  to  as  a 

PLAD.) 

Determination  of  the  appropriate  RI  for  a 
given  PLA  and  its  insertion  in  appropriate 
format  lines  of  the  message. 

A  designation  assigned  to  a  message  by  the 
originator  to  indicate  to  communications 
personnel  the  relative  order  of  handling  and  to 
the  addressee  the  order  in  which  the  message  is 
to  be  noted.  NOTE:  Precedence  designations,  in 
order  of  decreasing  precedence,  are  ECP  and 
CRITIC  (same  precedence  level),  FLASH,  IMMEDIATE, 
PRIORITY,  AND  ROUTINE.  These  are  defined  as 
follows:  (The  letters  indicate  the  corresponding 
prosi gn ) . 

ECP  Y  Is  designated  for  use  on  certain 

time-sensitive  command  and  control  emergency 
action  messages.  "Y"  is  designated’  Emergency 
Command  Precedence  (ECP)  and  has  FLASH  preemption 
capability  and  is  used  only  in  the  GENSER 
community. 

CRITIC  WW  Is  designated  for  use  on  certain 
time-sensitive  DSSCS  messages  and  has  FLASH 
preemption  capability  and  is  used  only  in  the 
DSSCS  community. 

FLASH  Z  Reserved  for  initial  enemy  contact 
messages  or  operational  combat  messages  of 
extreme  urgency,  and  CRITIC  messages  originated 
in  the  GENSER  community.  Brevity  is  mandatory. 

IMMEDIATE  0  Reserved  for  very  urgent  messages 
relating  to  situations  v/hich  gravely  affect  the 
security  of  national /al 1 ied  forces  or  populace. 

PRIORITY  P  Reserved  for  messages  concerning 
the  conduct  of  operations  in  progress  and  for 
other  important  and  urgent  matters  when  routine 
precedence  will  not  suffice. 
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ROUTINE  R  To  be  used  for  all  types  of 
messages  whicn  justify  transmission  by  rapid 
means  but  are  not  of  sufficient  urgency  and 
importance  to  require  a  higher  precedence. 

Preemption:  'he  reaTTocation  of  services  and  equipment  ■^rom  a 

lower  precedence  use  to  a  higher  precedence  use. 
That  is,  the  AJIPE  shall  have  the  capability  to 
preempt  the  output  of  a  message  to  allow 
transmission  of  a  specified  higher  precedence 
message;  preemption  shall  not  cause  the  loss, 
modification,  or  segmentation  of  a  message. 

Is  an  acquisition  concept  v/hich  programs  resources 
to  accomplish  the  orderly  and  cost  effective 
phased  grov/th  or  evolution  of  a  system's 
capability,  utility,  and  operational  readiness. 

The  telecommunications  center  provides  a  set 
number  of  copies  to  an  organization,  which  in 
turn  arranges  for  its  own  internal  distribution. 
NOTE:  Office  and  unit  determination  is  not 
performed  for  data  pattern  messages. 

The  rules  for  communication  system  operation  that 
must  be  followed  if  communication  is  to  be 
effected. 

R:  Refers  to  the  first  character  of  the  routing 

indicators  (alv/ays  an  R)  in  the  GENSER  community. 

Readdressal :  Those  actions  necessary  to  cause  a  message  stored 

on  the  message  storage  file  to  have  a  new  set  of 
addresses  assigned  which  differ  from  the  original 
set. 

RED/BLACK:  The  concept  that  electrical  and  electronic 

circuits,  components,  equipments,  systems,  etc., 
which  handle  classified  plain  language 
information  in  electric  signal  form  (RED)  be 
separated  from  those  which  handle  encrypted  or 
unclassified  information  (BLACK).  Under  this 
concept,  RED  and  BLACK  terminology  is  used  to 
clarify  specific  criteria  relating  to,  and  to 
differentiate  between  such  circuits,  components, 
equipments,  systems,  etc.,  and  the  areas  in  which 
they  are  contained. 

RI  (Routing  Indicator);  A  group  of  letters  assigned  to  indicate;  a.  the 

geographic  location  of  a  station;  b.  a  fixed 
headquarters  of  a  command,  activity,  or  unit  at  a 
geographic  location;  and  c.  the  general  location 
of  a  type  of  relay  or  tributary  station  to 


Preplanned  Product 
Product  Improvement 
(P^I) 


Protect: 


Protocol : 
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facilitate  the  routing  of  traffic  over  the  tape 
relay  netv/orks.  (JCSI) 


R/Y': 

Shal  1 : 

SHD  (Special  Handling 
Designator)  Synbol : 

SOM  (Start  of  Message); 

SPECAT  (Special  Category) 
Messages: 

SSN  (Station  Serial 
Number) : 


Refers  to  communications  facilities,  e.g.,  lines 
and  terminals,  that  process  both  GENSER  and  DSSCS 
traffic.  Note  that  such  facilities  are  "Y"  and 
belong  to  the  DSSCS  community,  but  are  allov/ed  to 
also  process  "R"  traffic. 

Statements  incorporating  the  verb  "snail"  are 
directive  on  the  contractor(s ) . 

A  five  character  field  consisting  of  one 
alphabetic  character  repeated  five  times.  The 
SHD  Symbol  appears  in  the  SPECAT  field  of  the  DD 
Form  173.  In  JANAP  128  format,  SHD  Symbols 
appear  in  format  line  four,  immediately  following 
the  classification/transmission  release  code 
field  (e.g.,  /AAAAA) . 

Sentinel  indicating  the  message  start  (V  or  Ltrs 
ZCZC  in  format  line  1). 

A  subset  of  special  handling  designations 
which  are  recognized  by  the  v/ord  "SPECAT" 
immediately  following  the  classification  in  the 
first  word  of  text.  In  addition,  the  appropriate 
SPECAT  DESIGNATOR  OR  SHD  repeated  five  times, 
preceded  by  an  oblique  (/)  will  immediately 
follow  the  security  characters  appearing  in 
format  line  4. 

A  message  reference  number  assigned  within  a 
a  comnunication/signal  center.  NOTE:  It  will 
normally  consist  only  of  a  number  allotted  in 
sequence.  Hov/ever,  in  those  instances  where 
station  serial  numbers  are  alloted  at  more  than 
one  position,  as  prescribed  by  in-station 
procedure,  a  single  letter  designator  can  follow 
each  number,  e.g.,  107A,  119B.  SSN  with  an 
alphabetic  character  is  not  allowed  in  the  DSSCS 
community.  The  message  reference  number  is 
normally  expressed  in  four  numerical  characters 
and  is  assigned  within  a  communication  center  for 
two  purposes,  viz.,  in  combination  with  the 
originating  station's  routing  indicator,  it 
provides  positive  identification  for  each 
transmission,  and,  as  the  validation  function 
number  appearing  in  format  line  15,  it  provides  a 
means  by  which  the  station  can  check  for  the 
existence  of  straggler  messages. 
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station  and  Channel 
Desi gnator: 


System  Controlled  Function: 


Subscriber; 


TAC: 


TARE  Line: 


TCC  (Transmission  Control 
Code) : 


TEP: 


Three  letters  which  identify  one  or  both  of 
the  stations  and  a  specific  channel  between  the 
two  stations.  These  are  used  as  follows: 

(1)  Either  two  letters  to  identify  one  or 
both  of  the  stations  and  one  letter  to  identify  a 
specific  channel,  or 

(2)  Three  letters  to  collectively  represent 
one  of  the  stations  and  a  specific  channel. 

A  function  that  is  performed  automatically  by  the 
AiMPE  system  (hardware/softv/are) .  Operator  action 
is  not  required  to  initiate  or  terminate  the 
function. 

An  IAS  subscriber  is  an  IAS  user  that  uses  its 
own  equipment  homed  to  an  IAS  element.  The  term 
"subscriber"  means  either  a  terminal  with  its 
associated  operator  or  a  host.  Subscribefs  are 
further  categorized  as  local  subscribners  and 
remote  subscribers.  A  local  subscribers  circuit 
terminates  on  the  I-S/A  AflPE.  A  remote 
subscribers  circuit  terminates  on  another  IAS 
element  (e.g.,  TAC),  and  the  remote  subscriber 
accesses  the  I-S/A  Af-IPE  through  the  network  to 
obtain  service. 

Terminal  Access  Controller,  a  host  subscriber  of 
the  DON  provides  the  Virtual  Connection  Service 
(i.e.,  TCP,  IP,  and  DON  interface)  via  THP  to 
terminal  subscribers  of  the  DON.  An  R-IS  terminal 
can  make  use  of  a  TAC  for  transport  to  its  home 
I-S/A  AMPE  for  Formal  Message  Service. 

Transmission  Instructions:  Transmission 
instructions  are  preceded  by  the  prosign  "T"  and 
indicate  specific  transmission  responsibility  not 
apparent  in  other  components  of  the  message 
heading.  These  instructions  appear  in  format 
line  four  of  the  message  heading. 

An  alphabetic  code  in  the  security  field  of 
the  message  header  which  is  verified  against  the 
destination  parameter  of  the  subscriber  to  ensure 
the  terminal  is  authorized  receipt  of  the  message 
contents. 

Traffic  Engineering  Practices  (for  the  Defense 
Communications  System)  DCA  CIRCULAR  300-70-1. 
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Term'  nal  : 


a.  Term' nal  s  are  usually,  but  not  always, 
located  with  the  ultimate  addressee  and  may 
provide  for  send  and/or  receive  operation.  The 
terminal  uses  the  automated  capabilities  of  an 
Af'IPE  to  perform  message  processing  functions 
which  would  normally  be  done  manually. 

b.  In  the  Packet  Processing  System  (DDM) 
terminals  are  defined  as  character  oriented 
devices  capable  of  conducting  conversation  with 
only  one  destination  at  a  time.  Terminal  devices 
may  be  computer  peripheral  controllers  and  or 
intelligent  or  unintelligent  input-output  devices 

c.  Message  Processing  Terminal:  A  terminal  that 
provides  a  basic  capability  to  process  messages 
to  and  from  AUTODIN  directly.  These  terminals 
may  be  either  leased  or  government  owned. 

Detailed  information  concerning  these  terminals 
is  contained  in  the  following:  DCAC  370-D175-1, 
DCAC  370-D195-3,  DCAC  310-D130-3,  and  DCAC 
370-D95-1 . 

d.  Local  Terminal:  In  the  IAS  a  local  terminal 
is  a  terminal  connected  directly  to  an  I-S/A  AMPE 

e.  Remote  Terminal:  In  the  IAS  a  remote 
terminal  is  a  terminal  directly  connected  to 
another  IAS  element  but  is  "homed"  to  an  I-S/A 
AMPE  for  certain  services. 

Throughput:  The  number  of  bits,  characters  or  blocks  which 

can  pass  through  a  data  communications  system  (or 
portion  of  that  system)  when  the  system  (or 
portion  of  the  system  measured)  is  working  at 
saturation.  The  throughput  will  vary  greatly 
from  its  theoretical  maximum. 

TRC  (Transmisson  Release  The  transmission  release  code  is  a 

Code):  two-letter  element  which  is  inserted  in  the 

message  heading  format  in  conjunction  with  the 
redundant  security  character  group  to  indicate 
authorization  for  the  transmission  of  any  U.S. 

DoD  GENSER  message  to  a  regional  defense 
organization  or  foreign  nation  (international 
traffic).  It  is,  essentially,  a  software  check 
on  the  release  of  a  message  to  non-U. S. 
subscribers. 

TRI-TAC:  Joint  Tactical  Communications  Office. 
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"RI-TAC  Message  Switched 
Meti/ork : 


Unique  Message  Identifier: 


User: 


Virtual  Connection  Service: 
Will : 

WIN  (WWI-ICCS  Intercomputer 
Network ) : 


The  TRI-TAC  message  switched  network  is  a 
common  user  network  consisting  of  TRI-TAC 
developed  store-and-forward  switches  (AN/TYC-39 
and  AN/TYC-ll)  and  existing  tactical  inventory 
tape  relays. 

a.  The  TYC-39  is  an  automatic  electronic 
store-and-forward  message  switch  under  processor 
control.  The  TYC-39  comprises  the  backbone  of 
the  TRI-TAC  message  switched  network. 

b.  The  smaller  capacity  TYC-ll  is  an  automatic 
message  switch  configured  for  inclusion  in  the 
TRI-TAC  Modular  Tactical  Communications  Center 
(MTCC)  to  provide  expanded  external  circuit 
termination  capability.  It  may  be  used  as  a 
concentrator  or  access  switch  for  subscribers 
requiring  access  to  the  TYC-39. 

The  global  unique  message  identifier  shall  be 
assigned  by  the  origination  I-S/A  AjMPE  and  shall 
uniquely  identify  the  message  globally  in  the  IAS. 

An  I-S/A  Af'IPE  user  is  any  organization  or 
activity  that  obtains  service  from  the  I-S/A 
Af-IPE.  A  user  may  obtain  this  service  by  use  of 
their  own  equipment  connected  to  the  I-S/A  AI-IPE 
or  by  obtaining  "over-the-counter"  service  from  a 
telecommunications  center. 

See  paragraph  3. 1.5. 1.4. 

Statements  incorporating  the  verb  "will"  are 
directive  on  the  Government  to  satisfy  in  support 
of  the  contracted  tasks. 

The  WViT-ICCS  Intercomputer  Network  (WIN)  is  a 
centrally  managed  information  processing  and 
exchange  system  designed  to  serve  the  corporate 
information  needs  of  the  NCA,  the  JCS,  the  CINC's 
and  Services.  The  WIN  consists  of  an  aggregation 
of  WWMCCS  computers,  WWMCCS  standard 
applications,  command  unique  applications, 
communications,  reporting  systems  and 
procedures.  The  term  WIN  encompasses  WV/MCCS  host 
computers,  designated  WIN  terminals  and 
interconnecting  communications  subsystem.  The 
WIN  communications  subsystem  consists  of  the 
Interface  Message  Processors  (IMPs),  inter-IMP 
trunks,  host-to-IMP  and  WIN  termi nal -to-host 
access  circuits  together  with  associated  modems, 
multiplexers,  concentraters  and  cryptographic 
equi pment. 
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World  Wide  Digital  Systen  Architecture 


Refers  to  the  first  character  of  the  routing 
indicators  {a1\^ays  a  Y)  used  in  the  DSSCS 
connunity . 


The  following  ternis  and  definitions  are  provided  to  achieve  a  better 
understanding  of  terms  used  in  computer  security  as  they  relate  to  the  l-S/A 
A»MPE  Program. 


Access.  The  ability  and  the  means  necessary  to  store  or  retrieve  data,  to 
comjnunicate  with  (i.e.,  provide  input  to  or  receive  output  from),  or 
otherwise  make  use  of  any  resource  in  a  computer  system. 

Access  Control.  A  strategy  for  protecting  objects  from  unauthorized  access. 

Access  Control  List.  A  list  of  subjects  which  are  authorized  to  have  access 
to  some  object.  See  Subject,  Object. 

Access  Level.  See  Security  Level. 

Access  Mode.  A  distinct  operation  recognized  by  the  protection  mechanism  as 
a  possible  operation  on  an  object.  Read,  write,  and  append  are  possible 
modes  of  access  to  a  file,  while  execute  is  an  additional  mode  of  access 
to  a  program.  See  Security  Mode. 

Access  Policy.  See  Policy,  DoD  Security  policy. 

Accreditation.  The  final  acceptance  of  a  system  for  operation  in  a  specific 
environment.  This  is  a  subjective  evaluation  of  a  system  based  upon 
certification  testing  and  environmental  analysis. 

Accountability.  The  property  that  enables  violations  or  attempted  violations 
of  system  security  to  be  traced  to  individuals  who  may  then  be  held 
respons ible . 

Activity.  A  security  model  rule  stating  that  once  an  object  is  made  inactive, 
it  cannot  be  accessed  until  it  is  made  active  again.  See  Bell-Lapadula 
Security  Model. 

Address  Space.  The  virtual  memory  that  can  be  address  by  a  process.  The 
maximum  size  of  a  process  address  space  is  usually  a  function  of  the 
underlying  hardware. 

AFFIRM.  A  formal  methodology  developed  at  USC-ISI  for  the  specification  and 
verification  of  abstract  data  types,  incorporating  algebraic  specification 
techniques  and  hierarchical  development. 

Aggregation.  A  circumstance  in  which  a  totality  of  small  pieces  of  information 
must  be  classified  at  a  higher  level  than  any  single  piece  of  information 
which  comprises  it. 

Attention  Character.  In  TCB  design,  a  character  that,  when  entered  from  a 
terminal,  tells  the  TCB  that  the  user  wants  a  secure  communications 
path  from  the  terminal  to  some  trusted  code,  in  order  to  provide  a  secure 
service  for  the  user,  such  as  logging  in  or  logging  out. 
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Audit.  An  independent  review  and  e.xarai nation  of  system  records  and  activities 
in  order  to  test  for  adequacy  of  system  controls,  to  ensure  compliance 
with  estaolished  policy  and  operational  procedures,  and  to  recommend  any 
indicated  changes  in  controls,  policy  and  procedures. 

.Audit  Trail.  A  chronological  record  of  system  activity  which  is  sufficient  to 
enable  the  reconstruction,  review,  and  examination  of  the  sequence  of 
environments  and  activities  surrounding  or  leading  to  each  event  in  the 
path  of  a  transaction  from  its  inception  to  output  of  final  results. 

Authe.n  tica  te .  To  confirm  the  identity  of  a  person  (or  other  agent  external  to 
the  protection  system)  making  an  access  request. 

Authentication.  The  act  of  identifying  or  verifying  the  eligibility  of  a 
station,  originator  or  individual  to  access  specific  categories  of 
information.  The  process  by  which  the  Government  determines  concurrence 
with  specifications. 

Authorize.  To  grant  a  subject  access  to  certain  information. 

3eii-l.apadula  Security  .Model.  An  "access  control"  type  of  security  model 
based  on  state-machine  concepts;  sometimes  called  the  MITRE  Model.  In 
this  model,  the  entities  in  a  computer  system  are  abstractly  divided  into 
sets  of  subjects  (active  entities  such  as  processes)  and  objects 
(information  containers).  The  notion  of  a  secure  state  is  defined,  and  an 
inductive  proof  of  system  security  can  be  given:  the  initial  system  state 
is  shown  to  be  secure,  and  every  state  transition  is  shown  to  preserve 
this  property. 

A  system  state  is  defined  to  be  "secure"  if  the  only  permitted 
accesses  of  subjects  to  objects  are  in  accordance  with  specified  security 
level  restrictions.  For  example,  a  subject  is  permitted  to  read  data  at 
its  own  level  or  at  a  lower  level  (  simple  security  condition),  and  to 
write  data  at  its  own  level  or  at  a  higher  level  (♦-property).  State 
transitions  preserve  the  "secure  state"  property  in  accordance  with 
tranquility,  erasure  and  activity  principles  (q.v.). 

Among  several  versions  of  the  Bell-LaPadula  Model  is  an  integrity 
model,  which  is  essentially  the  mathematical  dual  of  the  security  model, 
incorporating  a  "simple  integrity  principle"  and  "integrity  ‘-property." 
See  Integrity. 

Capability.  In  a  computer  system,  an  unforgeable  ticket  that  is  accepted 
by  the  system  as  incontestable  proof  that  the  presenter  has  authorized 
access  to  the  object  named  by  the  ticket.  It  is  often  interpreted  by  the 
operating  system  and  the  hardware  as  an  address  for  the  object.  Each 
capability  also  contains  authorization  information  identifying  the  nature 
of  the  access  mode  (e.g.,  read,  write). 

Category.  The  unit  into  which  security  information  is  partitioned, 

corresponding  roughly  to  an  interest  group  or  topic  area,  e.g.,  NATO, 
CRYPTO.  Category  information  can  exist  at  many  levels,  unclassified 
through  top  secret.  A  subject  must  be  cleared  to  an  adequate  level  and 
have  access  to  the  proper  category  or  set  of  categories  before  access  to 
classified  data  can  be  given.  See  Security  Level. 
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Certification.  The  application  of  policy  doctrine  and  technical  evidence  to  a 
system  to  determine  the  prudence  of  its  use  in  a  particular  secure 
application.  This  is  a  technical  activity. 

Channel.  An  information  transfer  path  within  a  system.  "Direct"  or  "overt" 
channels  are  those  paths  that  are  designed  for  data  transfer;  "indirect" 
or  "covert"  channels  are  not  explicitly  intended  for  data  transfer,  but 
can  pass  information  through  the  selected  use  of  system  resources,  that 
is,  through  "leakage"  or  "signalling."  Indirect  channels  are  generally 
categorized  as  "storage"  and  "timing"  channels.  Timing  channels  are  those 
that  exploit  the  system  clock  or  system  performance  characteristics  to 
pass  information  and  are  difficult  to  identify  in  a  non-procedural  system 
specification,  while  most  storage  channels  can  be  identified  by  flow 
analysis  techniques.  Both  types  of  indirect  channels  are  exploitable  only 
through  interprocess  cooperation. 

Classification.  The  level  of  protection  that  must  be  afforded  information. 

It  is  the  information  counterpart  of  Clearance  in  DoD  security  policy.  It 
applies  to  such  system  objects  as  buffers  and  files,  as  well  as  to 
"real-world"  security-related  documents. 

Clearance.  An  authorization  allowing  a  person  access  to  classified 

information.  This  is  a  "real-world"  term  used  in  connection  with  DoD 
policy,  whose  mathematical  counterpart  is  security  level  (q.v.).  A 
clearance  typically  consists  of  a  level  (unclassified  through  top  secret) 
and  a  need-to-know  category  or  categories. 

Code  Proof.  See  Implementation  Verification. 

Compartment.  See  Category. 

Computer  Program  Component  (CPC) .  A  CPC  is  a  functionally  or  logically 

distinct  part  of  a  Computer  Program  Component  Item  (CPCI)  distinguished 
for  purposes  of  convinience  in  designing  and  specifying  a  complex  CPCI  as 
an  assembly  of  Subordinate  elements.  (Para  5.D  .MIL  STD  483  of  31  Dec  70) 

Computer  Program  Configuration  Item  (CPCI) .  An  entity  that  will  be  tracked  by 
configuration  control.  The  aggregate  of  CPCIs  is  the  software  system. 

Computer  Security.  See  Security. 

Compromise.  The  known  or  suspected  exposure  of  clandestine  personnel, 

installations  or  other  assets,  or  of  classified  information  or  material  to 
an  unauthorized  person.  (JCSl) 

Confidentiality.  The  status  accorded  to  private  data  and  the  degree  of 
protection  that  must  be  provided  for  such  data.  Data  confidentiality 
applies  not  only  to  data  about  individuals  but  to  any  proprietary  or 
sensitive  data  that  must  be  treated  in  confidence.  See  Privacy. 

Confinement.  Allowing  a  process  executing  a  borrowed  program  (in  general,  an 
arbitrary  program)  to  have  access  to  data,  while  ensuring  that  the  data 
cannot  be  misused,  altered,  destroyed,  or  released.  See  Channel. 
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confinement  Channel.  See  Channel. 

Container.  A  repository  of  data  in  a  syste.m.  See  Object. 

Controlled  Security  Mode.  A  mode  of  system  operation  in  which  there  are  users 
who  have  legitimate  access  to  the  system  but  have  neither  a  security 
clearance  nor  need-to-know  for  all  classified  material  contained  in  the 
system.  However,  the  separation  and  control  of  users  and  classified 
material  is  not  essentially  under  operating  system  control  as  in  the 
multilevel  secure  m.ode .  Equivalent  with  compar t.mented  mode  (Ref 
D112M504).  See  Security  Mode. 

Correctness.  Formally,  the  property  of  a  system  that  is  determined  through 
formal  verification  activities.  Correctness  is  not  an  absolute  property 
of  a  system,  rather  it  implies  the  mutual  consistency  of  a  specification 
and  its  implementation.  See  verification. 

Correctness  Proof.  A  mathematical  proof  of  consistency  between  a 

specification  and  its  implementation.  It  may  apply  at  the  security  model 
to  formal  specification  level,  at  the  formal  specif ication-to-HOL  code 
level,  at  the  compiler  level,  or  at  the  hardware  level.  For  e-xample,  if  a 
system  has  a  verified  design  and  implementation,  then  its  overall 
correctness  rests  with  the  correctness  of  the  compiler  and  hardware. 

Cnee  a  system  is  proved  correct,  it  can  be  expected  to  perform  as 
specified,  but  not  necessarily  as  anticipated  if  the  specifications  are 
incomplete  or  inappropriate. 

Covert  Channel.  See  Channel. 

Data  Security.  Procedures  and  actions  designed  to  prevent  the  unauthorized 
disclosure,  transfer,  modification,  or  destruction,  whether  accidental  or 
intentional,  of  data. 

Debug.  Jargon  meaning  to  detect,  trace,  and  eliminate  mistakes. 

Dedicated  Security  Mode.  in  government  installations,  a  mode  of  operation 

in  which  the  computer  system,  its  connected  peripheral  devices  and  remote 
terminal  are  exclusively  used  and  controlled  by  specific  users  or  groups 
of  users  who  have  a  security  clearance  and  need-to-know  for  all  categories 
and  types  of  classified  material  contained  in  the  computing  system.  See 
Security  Mode. 

Denial  of  Service.  The  prevention  of  authorized  access  to  computer  resources, 
or  the  delaying  of  time-critical  operations. 

Design  Verification.  The  use  of  verification  techniques,  usually  computer- 

assisted,  to  demonstrate  a  mathematical  correspondence  between  an  abstract 
(security)  model  and  a  formal  system  specification.  See  verification. 

Discretionary  Access  Control.  Access  controls  to  an  object  that  may  be 

changed  by  the  creator  of  the  object.  More  generally,  mechanisms  that 
allow  each  subject,  at  its  own  discretion,  to  decide  which  of  its  own 
access  tights  ate  to  be  given  to  any  other  subject. 
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DoD  Security  policy.  The  complete  body  of  law,  regulations  and  policy 
concerning  the  safeguarding  of  Defense  sensitive  information.  DoD 
security  policy  includes  all  the  espionage  laws,  the  DoD  regulations,  and 
DoD  authorized  commercial  classification  for  handling  and  access  to 
information  concerning  national  defense.  The  basic  policy  sets  four 
levels  and  several  categories  on  non-discre tionary  information  control  and 
requires  that  anyone  accessing  classified  information  have  a 
"need-to-know"  for  the  particular  information  in  question.  See 
N'on-Discretionary  Access  Controls. 

Domain  (Hardware).  A  means  by  which  hardware  features  can  be  restricted  or 
nested.  For  example,  tne  DEC  PDP-11, '45  or  11/70  has  three  execution 
domains:  kernel,  supervisor,  and  user.  The  kernel  domain  is  the  most 
privileged,  and  allows  access  to  all  hardware  features  including  memory 
maps  and  I/O;  the  other  domains  do  not  allow  these  privileges.  Another 
example  is  the  Honeywell  MULTICS  architecture,  which  includes  eight  rings. 

Domain  (Software).  An  environment  or  context  that  defines  the  set  of  access 
rights  that  a  subject  has  to  objects  of  the  system. 

Downgrade.  See  Regrade. 

Edit/Reasonableness  Tests.  A  wide  range  of  tests  may  be  performed  on  items 
within  the  files  from  zero  to  excess  balance.  Thesetechniques  are 
searches  for  conditions  which  should  not  exist  if  controls  are  effective. 

Emulator.  A  combination  of  hardware  and  software  that  permits  programs 
written  for  one  computer  to  be  run  on  another  computer.  In  computer 
security  terminology,  the  emulator  is  the  portion  of  the  system 
responsible  for  creating  an  operating  system  compatible  environment  out  of 
the  environment  provided  by  the  kernel.  In  KSOS,  the  emulator  maps  the 
kernel  environment  into  the  UNIX  environment. 

Encryption.  The  (usually)  invertible  coding  of  data  through  the  use  of  a 

transformation  key  so  that  the  data  can  be  safely  transmitted  or  stored  in 
a  physically  unprotected  environment. 

Erasure.  A  security  model  rule  stating  that  objects  must  be  purged  before 
being  activated  or  reassigned.  This  ensures  that  no  information  is 
retained  within  an  object  when  it  is  reassigned  to  a  subject  at  a 
different  security  level.  See  Bell-LaPadula  Security  Model. 

Error.  An  error  is  an  item  of  information  which,  when  processed  by  the 
system,  produces  a  failure  (of  a  non-reproducible  type). 

Failure.  The  termination  of  the  ability  of  an  item  to  perform  its  required 
function. 

Fault.  A  malfunction  that  is  reproducible,  as  contrasted  to  an  error,  which 
is  defined  as  a  malfunction  which  is  not  reproducible. 

Fault  Isolation.  In  testing,  the  process  of  searching  for  and  locating  a 
defect  in  a  system. 


Flow  Analysis.  See  Security  Flow  Analysis. 

Flow  Control.  A  strategy  for  protecting  t.he  contents  of  information  objects 
from  being  transferred  to  objects  at  improper  security  levels.  It  is  more 
restrictive  than  access  control.  See  Access  Control,  Non-Discretionary 
secur i ty . 

Formal  Specification.  The  unambiguous  description  of  hardware  or  software 
in  a  language  with  a  well-defined  syntax  and  semantics.  These 
specifications  give  a  precise  mathematical  description  of  the  behavior  of 
the  system  being  specified,  computer  readability  of  these  specifications 
allows  for  automation  of  various  phases  of  the  verification.  Formal 
specifications  for  a  system  can  be  written  at  any  level  of  detail.  See 
Top  Level  Specification. 

Granularity.  The  size  of  the  smallest  protectable  unit  of  information.  In  a 
TC3  system,  this  would  be  the  size  of  the  smallest  protectable  file  or 
portion  of  virtual  memory. 

Human  Interface  Functions.  TCB  operations  that  require  human  intervention 

or  judgement.  Untrusted  processes  would  not  be  able  to  invoke  them.  See 
Software  Interface  Functions,  Trusted  computing  Base. 

Identification.  The  process  that  enables,  generally  by  the  use  of  unique 

machine-readable  names,  recognition  of  users  or  resources  as  identical  to 
those  previously  described  to  the  computer  system. 

implementation  Verification.  The  use  of  verification  techniques,  usually 

computer-assisted,  to  demonstrate  a  mathematical  correspondence  between  a 
formal  specification  and  its  implementation  in  program  code.  See 
Verification. 

Indirect  Channel.  See  Channel. 

Integration  Testing.  A  technique  used  to  test  groups  of  components  together, 
particularly  in  order  to  evaluate  the  correctness  of  shared  interfaces. 

Integrity.  The  assurance,  under  all  conditions,  that  a  system  will  reflect  the 
logical  correctness  and  reliability  of  the  operating  system;  the  logical 
completeness  of  the  hardware  and  software  that  implement  the  protection 
mechanisms;  and  the  consistency  of  the  data  structures  and  accuracy  of 
the  stored  data.  In  a  formal  security  model,  integrity  is  interpreted 
more  strictly  to  mean  protection  against  unauthorized  modification  or 
destruction  of  information. 

Interface.  A  boundry  or  point  common  to  two  or  more  similar  or  other  entities 
against  which  or  at  which  necessary  information  flow  takes  place. 

Interprocess  Communication  (IPC)  -  Communication  between  two  different 
processes  using  system-supplied  constructs,  e.g.,  shared  files. 

Isolation.  The  containment  of  users,  data,  and  resources  in  an  operating 
system  in  such  a  way  that  users  may  not  access  each  other's  data  and 


resoiirces,  and  rray  not  iranipulate  the  protection  controls  of  the  operating 
system.  See  Confinement. 

Level.  See  Security  Level. 

Mapping.  The  use  of  program  analyzers  to  determine  what  special  conditions 
lead  to  the  execution  of  each  program  module.  Use  requires  a  basic 
under s tsnding  of  the  application  system's  structure  and  application 
programming . 

.'■Mandatory  Security.  See  Mon-Discretionary  .Access  Control. 

MLS.  The  Multilevel  Security  flow  analysis  tool  developed  at  SRI.  See 
Hierarchical  Development  Methodology,  Security  Flow  Analysis. 

Multilevel  Security  Mode.  A  mode  of  system  operation  permitting  data  at 
various  security  levels  to  be  concurrently  stored  and  processed  in  a 
computer  system  where  at  least  some  users  have  neither  the  clearance  nor 
the  need-to-know  for  all  classified  material  contained  on  the  system. 
Separation  of  personnel  and  material  on  the  basis  of  security  level  is 
accomplished  by  the  operating  system  and  associated  system  software.  See 
Security  Mode. 

N’eed-to-Know .  A  job-related  requirement  for  access  to  specific  information. 
Meed-to-know  implies  discretionary  control  of  information — even  though 
potential  accessors  may  have  the  necessary  clearance. 

Non-Discretionary  Security.  The  aspect  of  DoD  security  policy  which  restricts 
access  on  the  basis  of  security  levels.  A  security  level  is  composed  of  a 
level  and  a  category  set  restriction.  To  access  an  item  of  information,  a 
user  must  have  a  clearance  level  greater  than  or  equal  to  the 
classification  of  the  information,  and  also  have  a  category  clearance 
which  is  a  superset  of  the  access  categories  specified  for  the 
information.  See  Discretionary  Access  Controls,  Security  Level. 

Non-Kernel  Security-Related  Software  (NKSR)  .  Security-relevant  software  which 
is  executed  in  the  environment  provided  by  a  security  kernel,  rather  than 
as  part  of  the  kernel.  Processes  executing  NKSR  software  may  or  may  not 
require  special  privilege  to  override  kernel-enforced  security  rules.  See 
Trusted  Process. 

Non-Procedural  Language.  A  formal  high-level  language  for  the  specification 
of  program  modules.  Such  languages  express  relations  which  hold  between 
"input"  and  "output"  values  of  program  variables,  without  constraining  the 
particular  algorithms  which  implement  the  change.  See  HDM,  INA  JO. 

Object.  In  a  formal  security  model,  an  identifiable  resource,  data  container 
or  related  entity  of  the  system;  the  counterpart  of  Subject. 
Software-created  entities  such  as  files,  programs  and  directories  are 
objects,  as  well  as  hardware  resources  such  as  memory  blocks,  disk  tracks, 
terminals,  and  tapes.  See  Bell-Lapadula  Security  Model,  Subject. 

Parallel  Simulation.  The  application  is  tested  by  using  the  same  input  files 
and  data  and  attempt  to  produce  the  same  results.  Unlike  ITF,  purging  of 
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files  is  not  required  because  the  si.-nula tion  is  run  parallel  to  the  "live" 
data  and  results  are  then  compared  to  the  "live"  results  confirming 
processing  or  identifying  areas  of  discrepancies  needing  further 
analysis.  Ail  or  parts  of  the  system  may  be  tested.  An  excellent 
verifier  of  controls. 

password.  A  protected  word  or  string  of  characters  that  identifies  or 
authenticates  a  user,  a  specific  resource,  or  an  access  mode. 

penetration.  The  successful,  repeatable,  unauthorised  extraction  of  recognize- 
able  infor.mation  from  a  protected  data  file  or  data  set. 

Penetration  Testing.  The  use  of  special  progr  ammer/analys  t  teams  to  attempt 
to  penetrate  a  system  for  the  purpose  of  identifying  any  security 
weaknesses . 

Periods  Processing.  In  computer  installations,  a  mode  of  processing  in  which 
a  specific  security  mode  is  temporarily  established  during  a  specific  time 
interval  for  processing  sensitive  information.  For  example,  the  computer 
system  could  process  secret  information  in  the  dedicated  security  mode 
during  one  period,  and  unclassified  material  in  a  second  period.  The 
computer  system  must  be  purged  of  all  imformation  before  transitioning 
from  one  period  to  the  next  whenever  there  will  be  new  users  who  do  not 
have  clearance  and  need-to-know  for  information  processed  during  the 
previous  period.  See  Dedicated  Security  Mode. 

Policy.  Administrative  decisions  which  determine  how  certain  security-related 
concepts  will  be  interpreted  as  system  requirements.  All  such  policy 
decisions  must  eventually  be  interpreted  formally  and  implemented. 

Privacy.  The  protection  afforded  to  information  in  a  communications  system  or 
network  in  order  to  conceal  it  from  persons  within  the  system  or  network. 

Privileged  Process.  A  process  that  is  afforded  (by  the  kernel)  some  privileges 
not  afforded  normal  user  processes.  A  typical  privilege  is  the  ability  to 
override  the  security  ‘-property,  privileged  processes  are  trusted.  See 
Trusted  Process. 

Process.  The  active  system  entity  through  which  programs  run.  The  entity  in 
a  computer  system  to  which  authorizations  are  granted;  thus  the  unit  of 
accountability  in  a  computer  system.  A  process  consists  of  a  unique 
address  space  containing  its  accessible  program  code  and  data,  a  program 
location  for  the  currently  executing  instruction,  and  periodic  access  to 
the  processor  in  order  to  continue. 

Protection.  Narrowly,  the  mechanisms  used  to  control  access  of  executing 
programs  to  stored  data.  See  Security. 

Quality  Assurance.  The  planned  and  systematic  pattern  of  actions  necessary  to 
provide  adequate  confidence  that  materiel,  data,  supplies,  and  services 
conform  to  established  technical  requirements  and  achieve  satisfactory 
per  formance . 
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Recovery  procedures.  lo  catia  ccrr-r-un  i  cat  ions ,  a  process  whereby  a  aata  station 
attempts  to  resolve  conflicting  or  erroneous  conditions  arising  during  the 
transfer  of  data. 

Reference  Monitor.  A  security  control  concept  in  which  an  abstract  machine 
mediates  accesses  to  objects  by  subjects.  In  principle,  a  reference 
monitor  should  be  complete  (in  that  it  mediates  every  access),  isolated 
from  modification  by  syste.m  entities,  and  verifiable.  A  security  kernel 
is  an  implementation  of  a  reference  monitor  for  a  given  hardware  base. 

Regrade.  A  determination  that  classified  information  requires  a  different 
degree  of  protection  against  unauthorized  disclosure  than  currently 
provided,  together  with  a  change  of  classification  designation  that 
reflects  such  different  degree  of  protection,  an  "upgrade"  results  in  a 
higher  classification,-  a  "downgrade"  results  in  a  lower  classification. 

Reliability.  The  probability  that  an  item  will  perform  its  intended  function 
for  a  specified  interval  under  stated  conditions. 

Ring.  See  Domain. 

Risk  Analysis.  The  term  applied  to  the  systematic  quantification  of 
threats,  loss  exposures,  and  countermeasures  benefits. 

Secure  Path.  See  Trusted  path. 

Security  (Computer  Security).  Used  in  the  most  general  sense,  this 

denotes  the  totality  of  mechanisms  and  techniques  that  protect  resources 
(including  data  and  programs)  from  accidental  or  malicious  modification, 
destruction,  or  disclosure.  The  term  includes  the  physical  security  of 
the  computer  installation,  administrative  security,  personnel  security, 
and  data  security.  Used  more  narrowly  in  a  verification  context,  it 
denotes  protection  of  computer  information  from  unauthorized  disclosure. 

Security  Flow  Analysis.  A  type  of  security  analysis  performed  on  a 

non-procedural  formal  system  specification  which  locates  potential  flows 
of  information  between  system  variables.  By  assigning  security  levels  to 
system  variables,  many  indirect  information  channels  can  be  identified. 
Security  flow  analysis  defines  a  security  model  similar  to  the  access 
control  model  (Bell-LaPadula )  but  with  a  finer  protection  granularity. 

Security  Kernel.  A  privileged  supervisory  operating  system.  A  localized 

mechanism,  composed  of  hardware  and  software,  that  controls  the  access  of 
users  (and  processes  executing  on  their  behalf)  to  repositories  of 
information  resident  in  or  connected  to  the  system.  The  correct  operation 
of  the  kernel  along  with  any  associated  trusted  processes  should  be 
sufficient  to  guarantee  enforcement  of  the  constraints  on  access.  TCBs 
have  been  implemented  using  security  kernels  along  with  trusted 
processes.  See  Trusted  Computing  Base  (TCB)  , 

Security  Level.  in  the  context  of  formal  security  modeling,  the 

fundamental  security  attribute  of  subjects  and  objects.  Security  levels 
combine  a  level  (e.g..  Unclassified,  Confidential,  Secret,  Top  Secret)  and 


a  set  of  nsad-to-kncv  categories.  A  derived  partial  ordering  of  security 
levels  is  defined  using  a  combination  of  the  "less  than"  order  on  levels 
and  the  "subset"  relation  on  category  set.  Thus  (Secret,  NATO)  is  less 
than  both  (Too  Secret,  NATO)  and  (Secret,  [NATO,  CRYPTO]).  The  security 
levels  (confidential,  NATO)  and  (Top  Secret,  CRYPTO)  are  incomparable. 

This  derived  partial  ordering  on  security  levels  is  the  basis  on  which  all 
s'ub ject-to-cb ject  access  is  determined. 

Security  Node,  A  Department  of  Defense  term  for  "Authorized  variations  in 

the  security  environments  and  methods  of  operating  ADP  systems  that  handle 
classified  data."  DoD  ADP  security  policy  (DoD  Directive  5200.28)  defines 
four  modes:  dedicated,  system  high,  controlled  and  multi-level  security 
modes . 

Security  Model.  See  Correctness,  Bell-LaPadula  Security  Model,  Security 
Flow  Analysis,  Verification. 

Security  policy.  See  DoD  Security  policy,  Non-Discr etionar y  Access 
Ccn  tr  ols . 

Security  Violation.  See  Violation. 

Security  ‘-property  (Star  Property).  A  security  model  rule  allowing  a 

subject  write-access  to  an  object  only  if  the  security  level  of  the  object 
is  the  same  or  higher  than  the  security  level  of  the  subject.  See 
Bell-Lapadula  Security  Model. 

Simple  Security  Condition.  A  security  model  rule  allowing  a  subject 

read-access  to  an  object  only  if  the  security  level  of  the  object  is  the 
same  or  less  than  the  security  level  of  the  subject.  See  Bell-LaPadula 
Security  Model. 

Snapshot.  A  technique  of  capturing  data  at  a  particular  point  in  time  in 
the  operations  cycle,  triggered  by  specific  transaction  types,  that  are 
identified  by  tags.  An  exellent  method  for  very  specific  purposes. 

Software  Engineering.  The  establishment  and  use  of  sound  engineering 
principles  in  order  to  obtain  software  that  is  reliable,  efficient, 
understandable,  maintainable,  economical  and  functional. 

Software  Interface  Functions.  TCB  operations  that  can  be  invoked  by 

software,  as  opposed  to  a  person  at  a  terminal.  See  Human  Interface 
functions.  Trusted  Computing  Base. 

Spoofing.  The  deliberate  inducement  of  a  user  or  a  resource  to  take  an 
incorrect  action. 

Specification.  Generally,  a  description  of  the  input,  output,  and 

essential  functions  to  be  performed  by  a  system  or  by  a  component  of  a 
system.  The  specification  is  produced  by  the  organization  that  is  to 
develop  the  system;  hence  at  the  top  level  it  can  be  thought  of  as  the 
contractor's  interpretation  of  the  requirements. 
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Storage  Channel.  See  Channel. 

Stractared  Progr  a.oaning .  .An  approach  to  progr  arating  the  pre.mise  ot  v/hich 
is  the  ase  of  a  small  set  of  simple  control  and  data  structures.  This 
rr.et.hod  typically  restricts  the  number  of  connections  between  program 
parts,  clarifies  module  entry  and  exit  points,  limits  module  size, 
restricts  arbitrary  branching,  and  incorporates  hierarchical  design, 
thereby  improving  comprehensibility,  reliability,  and  maintainability. 

See  Software  Ebigineer  ing . 

Subject.  .An  active  user  of  a  computer  system  together  with  any  other 
entity  onbehalf  of  a  user  or  on  behalf  of  the  system;  for  example, 
processes,  jobs,  and  procedures  may  all  be  considered  subjects.  Certain 
subjects  may  also  be  considered  to  be  objects  of  the  system.  See 
3ell-LaPadula  Security  Model,  Object. 

System  Control  .Audit  Review  File  (SCARF).  An  audit  trail  of  specified  trans¬ 
actions  built  into  the  program  to  tag  or  extract  exceptional  data  into  the 
audit  files.  During  normal  processing,  the  audit  tests  are  performed  on 
the  processed  data.  The  auditor  can  then  examine  bhe  review  file  and  draw 
the  appropriate  conclusions.  If  SCARF  testing  results  are  repeated,  it 
.may  indicate  that  the  controls  should  have  been  built  in  initially;  a  case 
of  audit  leading  to  improved  internal  program  controls. 

System  High.  The  highest  security  level  supported  by  a  system  at  a  particular 
time  or  in  a  particular  environment. 

System  High  Security  Mode.  The  mode  of  operation  in  which  the  computer  system 
and  all  of  its  connected  peripheral  devices  and  remote  terminals  are 
protected  in  accordance  with  the  requir em.ents  for  bhe  highest  security 
level  of  material  contained  in  the  system  at  that  time.  All  personnel 
having  computer  system  access  have  the  security  clearance  and  need-to-know 
for  all  material  then  contained  in  the  syste.m. 

System  Low.  The  lowest  security  level  supported  by  a  system  at  a  particular 
time  Or  in  a  particular  environment. 

System  Testing.  A  series  of  exercises  involving  the  test  of  the  completed 
system  by  an  outside  group. 

System  Utility.  Any  software,  not  part  of  the  verified  operating  system,  used 
to  perform  various  functions  that  are  not  directly  part  of  the 
applications.  Examples  ate  compilers,  debuggers,  editors,  and  loaders. 

Test  data.  Test  decks  ate  used  to  check  results  againstprede termined  values 
Little  ADP  knowledge  is  required  for  there  use  and  they  can  provide  a 
highly  specific  test  of  individual  control  features  and  exception 
conditions.  The  decks  ate  difficult  to  maintain  where  program 
modifications  are  frequent.  Usually  a  special  computer  run  is  tequitedfor 
there  use.  Since  they  are  oriented  to  known  controls  ,  the  it  use  will 
doubtfully  detect  the  absence  of  any  needed  controls.  Test  Data  Generator 
is  an  automated  development  of  test  transactions. 
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Testing.  The  controlled  exercise  of  program  code  in  order  to  expose  errors. 

It  co.nsists  of  exercising  the  software  and  accumulating  performance 
statistics  cn  its  operation. 

Thread  Testing.  A  technique  of  functional  testing  that  can  demonstrate  the 
operation  of  key  fttnctional  capabilities  fairly  early  in  testing 
activity.  n  thread  is  a  string  of  programs  that  when  executed, 
acccmplishes  a  distinct  processing  function. 

Timing  Channel.  See  Channel. 

Top-Down  Design.  The  decomposition  of  system  design  decisions  into  a 

succession  of  refinements,  from  the  more  general  to  the  more  specific. 

Top-Down  Development.  A  technique  for  implementing  hierarchically-structured 
progra.ms  in  which  top  level  routines  are  written  first.  For  test 
purposes,  lower  level  routines,  called  stubs,  are  written  to  interface 
with  these.  The  syste.m's  correctness  is  assumed,  not  proved,  until  the 
last  stub  has  been  replaced. 

Top  Level  Specification  (TLS)  .  In  a  verification  context,  a  mathematical 

specification  of  system  behavior  at  the  most  abstract  level,  typically  a 
functional  specification  that  omits  all  implementation  detail.  The  formal 
top  level  specification  of  a  security  kernel  precisely  defines  the 
behavior  of  the  security  kernel  observable  outside  the  kernel  domain  (at 
the  kernel  interface).  See  Formal  Specification. 

Trace.  A  technique  identifying  the  sequence  of  actual  exceptions  of  program 
code,  triggered  by  specific  transaction  types  identified  by  tags  on 
conditions.  Trace  may  also  be  used  to  document  use  of  program  modules  or 
instructions  to  process  specific  transactions. 

Tranquility.  A  security  model  rule  stating  that  the  security  level  of  an 
active  object  cannot  change.  See  Bell-LaPadula  Security  Model. 

Trap  Door.  An  entry  point  in  a  computer  system  that  can  be  selectively 
accessed  to  allow  unauthorized  access  to  the  system. 

Trojan  Horse.  A  borrowed  program  that  performs  actions  unrelated  to  the 
caller's  intent,  subverting  the  security  of  the  caller's  data.  It  may 
disclose  sensitive  data  either  by  hiding  it  in  a  file  or  other  form  of 
storage  where  it  can  be  accessed  later,  or  by  communicating  the 
infornation  via  a  covert  channel.  The  name  Trojan  Horse  was  given  to  this 
kind  of  problem  because  it  involves  a  foreign  or  gift  program  which  has 
unexpected  or  malicious  side  effects.  Trojan  Horses  may  be  planted  on  a 
temporary  or  permanent  basis.  See  Confinement,  Channel. 

Trusted  Computing  Base  (TCB)  .  The  totality  of  protection  mechanisms  for  an 
operating  system.  It  provides  both  a  basic  protection  environment  plus 
additional  user  services  required  for  a  trustworthy  turnkey  system.  TCBs 
have  been  implemented  as  security  kernels  and  trusted  processes. 
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Trusted  path.  A  reliable  ar.d  enforceable  connection  between  a  user  at  a 

terminal  and  a  trusted  process.  A  trusted  path  nuy  be  achieved  throuc'n  an 
attention  character.  Also  call  Secure  Pa  t.h .  See  Attention  Character. 

Trusted  Process.  A  process  in  a  position  to  affect  system  security.  It  is 
sometimes  but  not  always  endowed  with  privileges  to  override  TC3-enforced 
rules.  A  trusted  process  requires  reliable  confirmation  that  its 
protection  capabilities  or  characteristics  comply  with  stated  requirements 
(e.g.,  through  formal  verification).  Trusted  processes  are  sometimes  used 
to  execute  NKSR  software. 

Unauthorized  Disclosure.  See  violation. 

Un  tr  us  ted  Process.  A  process  whose  incorrect  or  malicious  execution  cannot 
affect  system  security,  verification  is  usually  not  applied  to  un  tr  us  ted 
processes . 

Upgrade.  See  Regrade. 

Validation.  The  collection  of  evaluation,  integration,  and  test  activities 
carried  out  at  the  system  level  to  ensure  that  the  system  being  developed 
satisfies  the  requirements  of  the  system  specification. 

Verification.  informally,  a  clear  and  convincing  demonstration  that  software 
is  correct  with  respect  to  well-defined  criteria,  such  as  a  security 
model.  In  a  formal  context,  verification  refers  to  the  mathematical 
demonstration  of  consistency  between  a  formal  specification  and  a  security 
model  (design  verification)  or  between  the  formal  specification  and  its 
program  implementation  (i.mplemen ta tion  verification).  The  phrase 
"formally  verified"  is  now  beginning  to  imply  that  computer-assisted 
techniques  have  been  employed  in  the  verification  effort.  See  Correctness 
In  testing,  verification  refers  to  the  iterative  process  of 
determining  whether  the  product  of  selected  steps  of  the  CPCI-developed 
process  meets  the  requirements  levied  by  the  previous  step. 

Violation.  Some  form  of  security  breaah.  "Compromise"  carries  the 

connotation  that  security-relevant  data  has  "possibly"  been  exposed  to 
uncleared  persons  (or  processes),  while  "unauthorized  disclosure"  implies 
Uhat  the  data  has  been  exposed  to  cleared  persons  who  do  not  possess  a 
need-to-know . 

Virtual  Space.  See  Address  Space. 

Walkthrough.  A  management  review  to  discover  errors  in  the  system. 

‘-Property.  Pronounced  "star"  property.  See  Security  ‘-Property. 
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MEMORANDUM  FOR  DISTRIBUTION 

SUBJECT:  Appendix  3B,  I-S/A  Al'PE  Message  Format  Validation  Criteria, 

to  the  I-S/A  A^PE  Functional  Statement  Document  (FSD) 


1.  The  purpose  of  this  letter  is  to  forward  a  copy  of  the  final  version 
of  Appendix  3B,  I-S/A  Al'PE  Message  Format  Validation  Criteria,  the  I-S/A 
ArPE  Functional  Statement  Document  (Enclosure  1).  This  document  also 
serves  as  Section  20,  ANPE  Message  Format  Validation  Criteria,  of  the 
I-S/A  A^PE  Functional  Requirements  Description/Interface  Control  Document 
(FRD/ICD)  and  should  be  inserted  therein.  This  final  document  contains 
all  of  the  Service/Agency  provided  requirements  with  respect  to  message 
format  validation  criteria.  This  concludes  formal  staffing  of  the  FSD 
and  all  portions  of  the  FRD/ICD  with  the  exception  of  Section  30, 

Security  Appendix. 

2.  The  requirements  contained  in  this  document  have  been  organized  and 

presented  in  such  a  manner  as  to  assist  the  Services  and  Agencies  in 
identifying  their  input.  The  I-S/A  AMPE  Specification  Working  Group 
currently  meeting  at  Gunter  Air  Force  Station,  Alabama,  will  review  this 
document  and  may  make  revisions  to  reduce  the  amount  of  duplication  which 
currently  exists.  If,  upon  review,  there  are  conflicting  criteria 
generated  by  these  requirements  which  cannot  be  resolved  by  the  on-site 
S/A  representative,  then  a  special  meeting  will  be  called  at  Gunter  Air 
Force  Station  to  resolve  these  issues.  . 
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I-S/A  AMPE  MESSAGE  FORMAT  AND  SECURITY  VALIDATION/VERIFICATION 


1.0.  Introduction. 

1.1.  I-S/A  AMPE  Channel  Parameter  Information.  In  this  appendix 
on  message  valldation/verlf Icatlon,  It  Is  always  assumed  that  the 
actual  characteristics  of  any  subscriber  terminal  match  those 
contained  In  the  I-S/A  AMPE  channel  parameters.  At  various  points, 
reference  will  be  made  to  these  characteristics  without  discussing 
the  problems  which  may  be  caused  by  incorrect  parameter  entries 
since  any  such  conflicts  should  be  resolved  in  testing  and  prior  to 
use  of  the  subscriber  terminal  for  "live"  message  traffic.  For 
example,  it  is  always  assumed  that  if  the  subscriber  terminal  is  a 
!!ode  I  using  a  Transmission  Identifier  line,  the  I-S/A  AMPE  is  set 
to  reflect  that  optional  capability. 

1.2.  Maintenance  of  Message  Integrity.  I-S/A  AMPE  message 
processing  shall  be  designed  such  that  both  the  loss  of  message  data 
within  the  I-S/A  AMPE  and  the  intermixing  of  data  from  different 
messages  (interlacing)  are  prohibited.  Garbling  or  changing  any 
single  character  within  the  I-S/A  AMPE  shall  be  minimized  by  the  use 
of  normal  internal  computer  verification  techniques. 

1.2.  Navy  LDMX  Vail d atio n  Philo s o phy . 

1.2.1  Validation  Philosophy.  The  LDMX  message  validation  is 

performed  to  insure  that  a  message  contains  all  of  the  properly 
formatted  data  to  allow  precedence  and  security  processing, 
addressee  routing  and  distribution  assignment,  transmissi jon  to 
"backbone"  or  other  networks  (where  appropriate)  and  data  to  allow 
LDMX  file  updates  for  message  recall  and  statistical  data 
gathering/audit  trails.  Most  format  errors  detected  by  the  LDMX  are 
sent  to  an  interactive  service  terminal  to  allow  LDMX  personnel  to 
either  correct  the  message  (interactively),  or,  if  appropriate, 
reject  the  message  to  an  LDMX  service  position.  See  paragraph  1.4 
for  interactive  error  processing  and  LDMX  service  position 
processing.  The  general  philosophy  of  LDMX  error  processing  is  to 
interactively  correct  all  errors  possible  without  compromising 
security  or  delivery  intention  assignment  by  the  message 
originator.  In  this  sense,  the  LDMX  performs  a  base  level  service 
to  it's  subscribers.  It  is  recognized  that  the  I-S/A  AMPE  is  both  a 
replacement  for  the  backbone  switching  centers  (ASCs)  and  the  base 
level  AJ'lPE's,  and  as  such  it  may  not  be  feasible  or  appropriate  for 
the  I-S/A  AMPE  to  provide  the  same  level  of  interactive  error 
processing/correction  as  that  of  the  LDMX. 
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1.3.  Message  Formats.  The  I-S/A  AMPE  shall  accept  and  process  a 
variety  of  message  formats  to  satisfy  the  requirements  of  different 
subscribers.  GEMSER  subscribers  will  utilize  formats  lAW  the  JANAP 
128  (  ),  AGP  127,  or  AGP  126  as  modified  by  Naval  Telecommunications 
Publications  (NTP)  4  (4),  hereafter  referred  to  as  Modified  AGP 
126.  DSSCS  subscribers  will  utilize  formats  lAW  the  DOI-  103,  the 
unique  DOI-103  Abbreviated  format  and  the  Streamliner  unique 
Abbreviated  format.  DSSCS  subscribers  who  have  a  requirement  to 
communicate  with  GENSER  subscribers  will  utilize  R/Y  channels  and 
will  comply  with  GENSER  formats.  It  is  noted  here  for  factual 
purposes  that  DSSCS  subscribers  are  directly  connected  to  DSSCS 
I-S/A  AiMPEs  only.  There  will  be  no  GENSER  subscribers  connected  to 
the  DSSCS  I-S/A  AMPEs;  however,  there  are  some  DSSCS  subscribers 
having  the  capability  to  send  and  receive  GENSER  traffic.  An  R/Y 
channel/port  can  be  likened  to  a  system  high  security  -  all 
applicable  elements  (i.e.  link,  operating  system,  facility,  and 
personnel)  meet  the  stringent  security  requirements  necessary  for 
certification. 

Note  that  with  some  limitations  for  special  formats,  the 
format  employed  by  a  subscriber  is  independent  of  the  mode  of 
operat ion. 

1.4.  Error  Processing.  When  I-S/A  AMPE  input  message  processing 
detects  unacceptable  errors  within  those  message  format  areas  that 
are  validated,  the  following  procedures  shall  be  followed: 

1.4.1.  The  I-S/A  AMPE  shall  record  the  error  condition  and  if  the 
detected  error  is  of  sufficient  seriousness  to  cause  immediate 
rejection  of  the  message,  a  reject  message  (RM)  control  character 
shall  be  generated  to  the  input  subscriber  terminal  and  a  service 
message  shall  be  generated  and  transmitted  to  the  input  subscriber 
citing  the  reason  for  the  message  rejection.  See  FRD  Section  21  for 
system  generated  service  message  conditions,  addressees  and  formats. 

1.4.2.  Upon  the  completion  of  the  format  error  detection  process 
and  when  at  least  one  error  has  been  detected,  the  1-S/A  AMPE  shall 
prepare  a  service  message  indicating  the  errors  found  and  whether  or 
not  the  message  has  been  accepted  or  rejected  and  forward  it  to  the 
subscriber  terminal.  On  any  message  rejection  by  the  I-S/A  AMPE  on 
a  controlled  line,  the  R,M  shall  be  generated  at  the  time  of 
occurrence  so  that  a  minimum  amount  of  data  is  involved.  If  the 
error  is  in  the  EOM  validation,  the  RM  shall  be  generated  at  that 
time  vice  an  EOM  ACK. 

1.4.3  Navy  LDMX  Interactive  Error  Processing.  The  heading 
analysis  modules  display  unprocessable  leading  lines  for  operator 
review  and  correction  or  rejection.  The  first  line  displayed  on  the 


console  screen  is  the  line  in  error  to  be  corrected.  The  operator 
will  use  the  first  three  spaces  proceeding  the  line  in  error  to 
indicate  the  type  of  correction  or  response  he  has  chosen.  Line  2 
provides  the  reason  for  line  1  being  unprocessable.  Lines  3-12  are 
10  lines  of  the  message  which  follow  line  1.  Lines  13-19  are 
filler.  Lines  20-22  contain  message  identification,  classification, 
and  system  control  data. 

The  VDT  operator  enters  a  one-character  Action  Code,  a 
period,  and  a  space  (example:  P.);  and  corrects  or  rejects  the 
displayed  error  line.  As  an  example,  the  operator  has  the  following 
response  options  in  correcting  an  invalid  short  title  in  format  line 

7. 

RESPON'SE  ACTION  OF  HEADING  ANALYSIS  MODULE 

L.  RUEDNKA/U.S .S .  BAINES  Accept  corrected  line  for  routing 

assignment  but  message  test  not 
corrected. 

P.  RUEDNKA/U.S.S.  BAINES  Accept  corrected  line  for  routing 

and  replace  the  incorrect  message 
line  with  the  corrected  line  as  it 
appears  in  the  response. 

X.  PROTECT  FOR  BAINES  Reject  the  message  to  the  service 

printer  with  the  annotation 
"PROTECT  FOR  BAINES”  (or  whatever 
message  is  appropriate  to  notify 
the  Service  Center  of  reason  for 
rejection  or  action  to  be  taken. 
(See  Para.  1.4.4.) 

Y.  TEXT  CLASS  ERROR  Reject  the  message  to  the  TS 

Control  with  the  annotation,  "TEXT 
CLASS  ERROR"  or  whatever  message 
is  appropriate  to  notify  TS 
Control  of  reason  for  rejection  or 
action  to  be  taken. 

C.  (SVC  note)  Ignore  processing  of  this  message 

line  and  continue  processing  the 
message  (not  valid  in  some 
cases).  If  a  note  is  included 
after  the  C.,  the  message  will 
also  be  sent  to  the  service 
printer  with  the  note. 

The  LDMX  Operator  Manuals  OM-OlB,  Volume  3  and  OM-02A, 
Volume  4  summarizes  the  allowable  response  options  for  various 
unprocessable  format  line  errors. 
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1.4.4  Interactive  VDT  Options.  The  VDT  operator  may  respond  to 
an  error  wTth  one  of  five  different  options.  The  type  or  response 
acceptable  for  each  format  line  is  validated. 

1.4. 4.1  Options . 

1.4. 4. 1.1  xxxx" .  This  signifies  that  the  VDT 
operator  wants  to  reject  the  message  to  the  Service  Center.  The  VDT 
operator  may  attach  a  narrative  to  the  response  (xxxx).  The 
narrative  is  appended  to  and  printed  with  the  message  at  a  service 
position. 


1.4. 4. 1.2  "Y."  or  "Y.  xxxx"  This  signifies  that  the  VDT 

operator  wants  to  reject  the  message  to  the  TS  Courier.  The  VDT 
operator  may  attach  a  narrative  to  the  response  (xxxx).  The 
narrative  is  appended  to  and  printed  with  the  message  at  the  TS 
Courier . 


1.4. 4. 1.3  "C.''  or  "C.  xxxx"  (Continue).  This  response  is  used 

when  the  VDT  operator  does  not  want  to  correct  the  error.  The  line 
in  error  will  be  ignored  and  processing  will  continue  with  the  next 
line  of  the  message.  The  "xxxx”  is  an  optional  service  line  which 
can  be  either  the  line  in  error  or  a  comment  added  by  the  VDT 
operator. 


1.4. 4. 1.4  "P.  xxxx"  (Physical  Change^.  This  signifies  that  the. 
VDT  operator  wishes  to  replace  the  entire  line.  Both  the  line  in 
error  and  corrected  line  are  properly  identified  for  subsequent 
processing.  All  routing  and  distribution  is  done  according  to  the 
corrected  line. 

1.4. 4. 1.5  "L.xxxx"  (Logical  Change).  The  VDT  operator  wishes  to 
use  the  input  argument  (xxxxx)  in  reprocessing  the  line  and  wants 
the  line  to  remain  unchanged  in  the  message.  7or  a  logical 
correction,  the  new  data  entered  through  the  VDT  will  be  used  to 
process  the  line,  but  the  original  line  will  be  saved  for  subsequent 
processing. 

1.4. 4. 2  Exceptions. 

1.  No  continuations  (C.)  are  permitted  on  format 
lines  2  through  4  and  13  through  16. 

2.  No  logical  changes  (L.  )  are  permitted  on  format 
lines  7  and  8  for  sideroutes  or  on  format  line  11. 

1.4.5  LD^  Service  Position  Processing.  The  service  position 
consists  of  a  service  clerk,  a  lino  printer  to  list  messages 
rejected  by  the  system  or  interactive  operators,  and  an  interactive 
display  console  for  entering,  recalling,  or  editing  messages. 
Basically,  the  clerk  has  four  approaches  to  processing  messages 
received  at  this  position: 
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a.  Using  his  interactive  terninal,  recall  the  nessage 
in  error  and  correct/pilot  the  error  as  required  and  re-enter  the 
nessage  for  processing.  The  nessage  is  then  treated  as  a  new 
nessage. 

b.  Service  the  originator. 

c.  Both  of  the  Above. 

d.  Deliver  the  nessage  by  alternate  neans  (other  than 

AMPE). 

2.0.  General  Connents  -  GENSER 

2.1.  Fornat  Line  1  -  Transnission  Identifier  Line  and  Pilots.  A 
Transni ssion  Identifier  (TI)  line  is  transnitted  ahead  of  each 
nessage  on  all  asynchronous  and  sone  synchronous  terninal  channels. 
For  asynchronous  channels  (Mode  II  and  Mode  V),  the  TI  line 
incorporates  a  Start-of-Message  Sequence  (SOMS);  the  Channel 
Designator  (CD),  and  a  three-digit  Channel  Sequence  Munber  (CSM). 

For  synchronous  channels,  full  channel  controls  nake  use  of  a  TI 
line  unnecessary  but  TI  use  is  available  as  an  option  if  terminal 
procedures  make  nessage  accountability  by  CSM  desirable.  The  CSH  is 
initialized  to  001  at  terminal  or  I-S/A  AMPE  start-up,  and  normally 
continues  to  999  at  which  point  it  "rolls  over"  to  000,  then  001, 
etc. 


2.2.  Asynchronous  Channels.  A  Transmission  Identifier  (TI)  line 
is  mandatory  for  all  traffic  sent  to  the  I-S/A  AMPE  by  a  teletype 
(asynchronous)  subscriber  terminal.  This  line  must  consist  of  the 
Start  of  Message  Sequence  (SOMS),  "ZCZC",  followed  by  a  three 
alphabetic  character  Channel  Designator  (CD)  or  Channel  Identifier 
(CID).  This  is  followed  for  five  level  (ITA2)  terminals  by  the 
figure  shift  (FIGS),  which  in  turn  is  follo\/ed  by  a  three  numeric 
character  channel  sequence  number  (CS‘I).  For  five-level  terminals, 
the  CSN  is  follo\/ed  by  the  letters  shift  (LTRS)  machine  function 
and,  in  normal  operations,  by  the  End-of-Line  (EOL)  sequence  of  two 
carriage  returns  (CR)  and  one  line  feed  (LF). 

2.2.1.  To  avoid  loss  of  the  first  SOMS  character  due  to  occasional 
signal  path  instability  or  terminal  mechanical  equipment  start-up 
delay,  the  SOMS  may  be  preceded  by  the  letter  "v"  as  a  "throvjaway 
character",  but  the  I-S/A  AMPE  shall  not  require  this  letter  for 
proper  recognition  of  the  SOMS  if  the  "ZCZC"  sequence  is  correct. 

2.2.2.  Detection  of  two  consecutive  SOMS  by  the  I-S/A  AMPE  withotit 
an  intervening  EOMS  shall  result  in  rejection  of  the  presumed 
incomplete  message  for  "Two  Consecutive  SOMS."  On  a  Mode  II 
channel,  the  second  message  shall  be  accepted  if  it  is  otherwise 
valid.  On  Mode  I  and  V  channels,  the  second  message  shall  also  he 
rejected. 


2.3.  Synchronous  Channels.  While  the  TI  line  is  nandatory  on 
all  asynchronous  channels,  it  is  an  option  for  Mode  I  (synchronous) 
subscriber  terainals. 

2.3.1.  Since  the  synchronous  user  employs  line  block  framing  with 
the  SOH  character  as  the  first  character  of  the  message,  the  "ZCZC" 
sequence  is  not  employed.  Instead,  the  first  character  following 
the  SOH-SEL  framing  characters  is  the  letter  "C".  This  is  followed 
by  the  CD,  the  figures  shift  (if  the  select  character  is  an  "A" 
indicating  message  preparation  in  five-level  paper  tape),  the  CSN, 
and,  again  for  "A"  select,  a  letters  shift.  No  EOL  is  necessary, 
but  the  TI  line  will  occupy  a  block  by  itself  with  no  header  data  in 
the  TI  line  block.  The  TI  line  block  may  either  be  terminated  with 
an  Efi  character,  or  filled  out  to  a  full  80  data  characters.  No 
data  past  the  CSM  shall  be  validated,  and  any  remaining  characters 
in  the  line  block  shall  be  discarded  by  the  I-S/A  AfIPE. 

2.4.  Hessage  Header  Validation  -  Introduction.  The  I-S/A  AHPE 
shall  perform  validation  on  message  headers  not  only  to  insure 
correctness  for  such  purposes  as  security  and  precedence  but  also  to 
ensure  that  the  routing  indicators  are  valid  for  delivery. 

2.4.1.  The  I-S/A  AMPE  shall  validate  both  the  header  and  the 
trailer  (either  the  End-of-Hessage  Sequence  (EOMS)  or  the  trailer 
card)  of  all  messages.  This  shall  include  checking  of  the  header 
station  serial  number  against  that  contained  in  the  trailer  to 
protect  against  a  straggled  message  -  that  is,  a  message  following 
one  with  a  garbled  trailer  or  EOfiS  as  one  transmission.  (See  para 
4.3.5.) 

2.4.2.  Before  discussing  the  specifics  of  header  validation,  here 
is  some  additional  information  on  what  are  termed  "combined  R  and  v 
Community  channels".  These  are  correctly  termed  ''  Comiinity  (DSSCS) 
channels  over  which  R  Community  (CENSER)  traffic  may  be  sent.  It 
shall  be  permitted  for  these  channels  to  use  different  formats  for 
the  t\/o  communities.  That  is,  these  R/Y  channel  subscribers  may  use 
either  a  pre-established  format  lAW  JANAP  1 28  (  ),  ACP  1P7,  or 
Modified  ACP  126  to  transmit  CENSER  messages  and  a  pre-established 
format  lAH  DOI-103  or  the  DSSCS  Abbreviated  formats  to  transmit 
DSSCS  messages  but,  with  the  exception  of  CRI^ic,  formats  cannot  be 
mixed  within  the  community.  This  point  is  brought  forth  here 
because  proper  processing  of  the  message  depends  on  determination  o^ 
the  community  of  the  traffic.  If  the  message  is  garbled  and  an 
error  is  made  in  this  determination,  the  message  shall  always  he 
rejected. 
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S  3  2.  Routing  Indicators  are  not  used  in  Format  Lines 
7  or  3  proceeding  the  FLA,  except  when  an  addressee  has  been 
designated  delivery  responsibility.  It  is  used  to  designate 
a  specific  activity  as  communications  guard  or  cryptoguard  for 
an  addressee  luno  has  no  assigned  routing  indicator.  When  such  a 
procedure  is  used,  the  station  routing  indicator  responsible 
for  delivery  is  suffixed  with  a  "C"  and  placed  in  format  line  7 
or  3  proceeding  the  activity  with  cryptoguard 
-  e  3  p  o  n  s  b  ’  i  1  t  y  .  E  r  a  m  c  1  e 


‘YVX.X  aXC,  SI  TE  TWO" 


1 


COLLECTIVE  ADCRESSINC 


3.  2.  1.  1.  In  the  DSSCS  co.nmunity  "DS3CS  Addressing 
Croups''  (DAOs),  (Ref  paragrapn  w  11)  and  Product 

Distributions  (FD)  (Ref  paragraphsg  1  A  -and  I  1  5)  may  be 
used  in  iieu  of  listing  each  FLA, 


S  3.  2.  1  2.  D.AGs  consist  of  5  alphebetic 
and  are  general  purpose  addressing  groups,  wnich 
•ninimum  of  5  addressees  The  majority  of  the 
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one  or  rr.ore  addressees  from 
he  exclusion  address  is  in 
£33"  addressee,  i -mediately 
e  re  5  sac  e. 


GW 


the  originator  can 
a  DAG  for  a  specific 


dicated  in  the 
following  the 


message  as 
If.G  in  the 


a  d  d  ~  e  3  3 

d  or  r 1  on 

of  t 

E'.tA'iPLE 

"TG  :c 

RPEC-C 

lES5 

5TATI 

i_£E3 
ETC  " 

-/  1  -*  i  A 

'2  Z  1  1  C 

3  " 

a  A  ‘jJT  Z 

,!•  1  - 

tide  man- 

7  :  n  ^ 

;  r  7 

d  j  T-  e  s  s  e  r  e 


j  ;)  It."!  a  -  'j  n  u  r.  P  e  -  of 

'  "  u  “  -  1  i  C  U  1  j  "r  <  =  ("n  0  A  '5  3  u  0  'J  S 

cvore;-inted  b  ■.!  the  C^-G  are 


i  e  r  t  e  d 


5~ATIGJ  13 


V'  -•  ■'■'Ad. 


Ji 


J 


•  C  •hP.  ifc-A  A  ^ 


I  dM  ara  If '^a 


U.'-iCLASS  if  I  ED 


^  2.  2.  2  Two  or  ,71  ere  DAG 5  may  be  u  =  ed  for  addressing 
i  message;  sJlt^  either.'or  additonai  or  LESS  addressees 

■or  each  DAG  Folloujing  is  an  example 


EXAr-^PLE: 


"TO  GHHCD 
LESS  STATION  21 
RANGE 
w  t  i  I  I:  t'*!  w  ’ 

8  2.  2.  3.  PRODUCT  DISTRIBUTION 


''3  2  2.1  Product  dist~ibution  symbols  are 
composed  o*  t_iO  elemencsi  eacb  separated  by  a  slant  (no 
space).  The  -irst  element  is  the  PLA  of  the  or  i’g  mating  unit  The 
second  IS  a  lercer  or  letter- s  that  equate  to  the 
specific  addressees  (for  exam.cle  NSA/DELTA  -or  NSA/ALFA  CHARLIE). 


A  P  D  may  cor 
paragraph  2.  3.  1. 


contain  more 


than  12  characters 


.  t  a  t e  d  in 


3  4  PAGING  OF  TRAFFIC 

S  2  1.  Paging  -of  .message  traffic  with  in  the  DSSCS 
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8  5  flESSAGE  LEN'G'Th 

2.3,  1  DSSCS  imessage  len.gth  is  40,001  chamacters,  except 
“or  those  messages  that  are  routed  to  or  through  any 

collaborating  c  ommun  1  c  a  1 1  gn  cente-  or  inobile  mit,  which  are 
iimite-d  to  5400  :  h.  ar  ac  t  - -m  ; ,  per  D0I-i03. 
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S  6.  2.  On  dual  precedence  messages  in  uhich  both  the 
action  and  information  precedences  are  IMMEDIATE  or  louder/ 
then  the  action  precedence  is  placed  in  the  message  header 
and  only  one  tranmission  is  req^uired. 


7. 1.  Uhen  che  classification  and  special  handling 
instructions  do  not  dictate  an  output  format  the  sytem 
shall  use  the  addressees  to  determine  the  output  format.  If 
a  addressee  is  duplicated  across  communities  (CENSER  and 
DSSCS)i  the  I-S/A  AMPE  shall  try  to  format  the  data  according  to 
other  addressees  in  the  data  that  can  identify  a  specific 
community  of  interest.  If  the  data  contains  only  duplicate 
addressees  and  the  classification  (to  include  the  message 
handling  instructions;  does  not  dictate  and  absolute  community  of 
interest  routing-  the  1-3. -'A  AhPE  shall  defer  the  formatting  and 
routing  to  the  DS3C3  community. 


Uhen 


DSSCS)i  the  1-3/A  Af'^PE 


o  th  ei 


address: 


community  of  interest, 
addressees  and  the 


sectignalizaticn 


8.  1.  Message  uhich  e/ceed  40,000  characters  (500 
cards)  for  "lODE  I  an-i  MODE  V  terminals  and  10-000  characters 
for  MGCE  II  term ijials  are  considered  long  messages  and  'Kill  be 
divided  into  tran imi ; s  ion  sections.  Messages  routed  to  or 
through  any  c  o  i  I  ad  or  a  1 1  n  oomnun  i  ca  t  i  or.s  facilities-  or 

mobile  units  are  limited  to  "00  groups  (5400  characters;  and 
must  be  divided  into  transmission  sections.  Those  message 
or  1  g  1  n  a  1 0  "  s  having  unicue  or  special  r  e  qu  i  •' emen  t  s  for  repeated 
preparation  and  transmission  of  messages  containing  40-000 
charac"e~s  ■  5C  0  cards)  should  coordinate  'Kith  each 

add-essee  termiral  -or  the  continuous  acceptance  of  long 
messages 


r-arded  im  far,  s  mission  s.sctions 

n  V  i  n  i  e  n  t  point.  out  not  b  e  'j  o  r  d  the 
1  D  e  d  I  miT.  e  d  1  a  t  e  1  1  F  o  i  1  o  u  i  n  .g  the 

codeuorj-  or  restrictive  handling 

nsert  "SEITIGfi  1  CF  _ ",  Each 

r-ction  uiii  be  loentiried  as  "  3.3C  T I 'GN 

*■  I  1  0  •?  * '  -  1  -Z  ii  i.  iTt  ■?  s  E  £j  Z  ^  5  a  j  1  r.  >4  «  3  s'  C  =  p  l 

1  “  f  r  e  ri  t  station  s  e  t’  i  a  1  number  -  o 


20 


Ur^CLASSIFIED 


each  t-ans mission  section.  The  final  transinission  section  will 
be  identified  as  "FINAL  SEC7ICN  CF 


8  8,3.  All  i  n  f  OT’C'.a  1 1  on  from  format  line  5  through  the 

first  full  telet',  pe  line  of  the  "SU3J"  line  of  format  line  12 
IS  carried  over  to  all  sections  of  a  multi-section  message 


S  ?.  END-GF-Lir^E  F'jr,iCTICrj3 


8 


‘he  normal  end-of-line  functions  will 


b  e 


carriage 


:ur  ns 


line  feed, 


unless  DS3CS  operating 


signals,  e.  g  •  'ZZP"  or  "ZNZl",  appears  in  Format  Line  5 
10.  CANCELLING  TRANSMISSIONS 


8  10  1.  The  I-S,^A  AMPE  and  DSSCS  terminals  must  be 
able  to  recognice  and  generate  a  cancel  transmission  (CANTRAN) 
secguence 


S  10  2.  Input  DSSCS  terminals  can  cancel  a  transmission 
in  one  of  two  wags  1)  bg  depressing  the  "CANCEL"  control  button 
on  MODE  and  certain  NODE  I  terminals)  2)  NODE  II  terminals 


must  use  the  C.anTRAN  sequence  of  SE '  s  AR.  optional  for  MODE  I  and 


8  - 


d  e  t  act 


an  : 


discard 


J.  The  :-5.'A  Ar'PE  must 
cancel! transmissions/  tg  either  a  con  trol  c.haracter  or  CANTRAN 
seo.uence  ,A  C.>'v'4TP.*-N  sequence  is’  "■C.!='E  E  E  E  E  E  E  E 
AP  ; -!-  =  =  -  =  =  ==JirM-'N "  /  a  minimum  requirement'  "".-r^E  E  AP,  =  -NNr4N" 


^  !■:  3  1 

ill  0  e  i 

3  10  Z  2 


'he  C.-NTPAN  sequence  gena-’ated  bg  the  I-S/A 
f  o lows'  '  C '!=='f An  CC'C' 1  E  E  E  EEEEE 


r-.  • 


■  e a • d  0 w n  of 
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I -S/A 


10.  3 


'A3C"  is  the  Channel  Desianator  fCD)  of 


tre  I-S/A  aV.PE  generating  the  CAUTRATJi  if  applicable 

«10  3.  T.  3.  "001"  is  the  Channel  Sequence  Number 
(CSN)  of  ®the  transmission  that  is  being  cancelled  TI 

’•ines  are  not  used  the  terminal)  the  I-S/A  AKPE  uill  "C599'>  jn 
this  field. 


g  .10  3  2,  4  "E  E  E  E  E  E  E  E  AP 
mg  "cancel  this  transmission" 


the  prosign 


8-10  3  2.  5  All  CAtiTPAiiE  uj  i  1  1  be  i  .nm  e  P  i  a  t  e  1  g  folloii’ed 
b'j  a  valid  EON  sequence  of  2  carriage  returnsi  B  line  feeds  and 


r 0 ur  N  s 


3,10  4  If  the  I-E/A  ANPE  must  cancel  an 
t-ansmission  currently  in  progress  it  ^jill  se 
ccncroi  character,  al'uags  *olloued  by  t'le  CApirr-s,',  sequ 


c  e 1  an  outgoing 
ijill  send  a  cancel 


*'.10  5  Cn  card  nessages,  the  cancel  ;atv~r  is  indicated 
by  t ''  e  eighth  punch  in  the  S 1  s  t  c  o  1  v' m  n  of  the  .rare 

3.11  CCMEBACX  COPY 

3,2  11  1  The  I  -  S  '  A  t.'.pt>c  shell  pr  o iJe  tre  c  up. s  hi.  it,  for 

t.ie  input  t  erm  1  r.a  1 ,  or  ;  g  1  na  t  o  o-  a  Tiesra:^'  to  rc-cei-e  ll  a  fully 
*  0  r  .n  a  1 1  -  d  t  o  p  y  of  the  o  t  g  o  i  n  g  .m  e  s  s  a  a  c- ,  c  r  2  ■  the  as  i'  e  c  e  ;  e  d 
-ersion  including  tre  distribjt;  ii,  a  no  Jr:3rter  r.=  ieaser 

1  r,  f  .p  ;■  ;i  t  1  .e n  or  both  1  arc  2  'he  0 p  t  ;  r n  2  .  :  -i e  b  a  c  '•  c  o  p  u  s  a  1  1 

r-efiect  the  hig.^est  c  1  as  s  i  f  i  ca  t :  on  of  i-ith-^  t'-'e  n'--spage  or  t^e 
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3.12  FORf^AT  VALIDATICN 

3.12.1  The  folio 'ijing  precedences  are  authorized  uiithin  the 
DSSCS  community: 

14  -  CRITIC 
2  -  FLASH 
Q  -  IMnEDlATE 
P  -  PRIORITY 
R  -  ROUTINE 

3.12.2  The  I-S/A  AHPE  shall  recognize  a  CRITIC  message  in 
any  one  of  four  possible  message  formats. 

DD-173  Joint  Hiessage  Form  Data 
APbreviated  Message  Format  ( AMF ) 

DO  1-103  Special 
JANAP  128 


3.12.3  CRITIC  Hessage  -  The  I-S/A  AHPE  shall  examine 
incoming  transactions  only  to  the  extent  necessary  to 
verify  that  a  transaction  is  a  CRITIC  message  14 o  format  or 
validation  checks  'jiill  be  performed  once  a  messaae  has  been 
recognized  as  a  CRITIC 

EXAHPLE: 

FORHAT  LINE  1  ZCZCASC123 
FCRr-AT  LI.NE  2  .vN  •  £- AAH 
FCR-'.AT  LlN'E  In  ;  ;  =  =  -=====^r>N'r'4 

The  I-S  A  A-’=^  sn.all  h  ancle  a  DD-lTO  Jo  mo 
as  a  IRIT'C  i-  she  -olio 'j;  mg  t^'C  criteria  are 

iz  a  ‘N*  appears  in  eithe"  the  ui  iLiTJ  or 


3.12^3.1 
H  e  5  5  a  g  ?  norm 
met. 


3.12.3.1.1 


INFO 
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3.12.3.1.2  The  ujord  "CRITIC"  appears  in  the 
"Or i g /Mes sag e  Ident"  block, 

3.12.3.2  either  of  the  above  criteria  is  met  and  the 
other  is  not,  the  I-S/A  AltPE  shall  divert  the  data  to  an  error 
correction  console  and  notify  the  operator  with  a  unique  visual 
and  audible  alarm. 

3.12.3.3  The  I-S/A  Ar'PE  shall  handle  an  AHF  formatted 
message  as  a  CRITIC  if  F/L  3  contains  the  folio 'ijing  data: 

3.12.3.3.1  The  message  precedence  is  "W". 

3.12.3.3.2  The  message  precedence  is  follo'jjed  by  "space 

CRITIC". 

3.12.3.4  PoT'  3  JA^'AP  ■  123  formatted  message  to  be 

recognized  as  a  CRITIC,  the  precedence  must  be  "2",  the  Routing 
Indicator  must  be  "RUETIAA",  and  the  word  "CRITIC"  must  appear  in 
F/L  12  followed  by  a  space,  carriage  return,  or  line  feed.  If 
the  word  CRITIC  is  preceded  or  followed  by  "FDLLOU-UP"  or 
"L.ATERAL"  the  message  shall  not  be  handled  as  a  CRITIC.  Upon 

recognition  of  a  CENSER  CRITIC,  the  I-S/A  AITPE  shall  process  the 

CRITIC  as  in  Para  3.12.3 
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j_  1 

a 
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r  • 
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a  n  a  c 
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12.3.7 

The 

I -3  'A 

-^•'•PE  shall 

s  e  0  a  r  a 

te  CRITIC  ,-nessages 

b  a 

Bed 

C  1 

one 

0  f 

—  L  j 

*  3  1  i,  0  u;  I  n  g 

c  r ; ter 

;  a  whic.''.  aapl’i 

to 

*  c 

T  r\atz 
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1 

:  B  *:  e  b 

in  p 

aragr ap 
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3.1213.  7.  1,  A  valid  End-o  f -!^a  5  aa  g  e  '  EOM  )  indicator  has 
been  received.  The  End -o f-Mes sa g e  sequence  is  defined  in  MIL- 
STD-iae-C. 

3.12.3.7.2.  During  the  receipt  of  a  CRITIC/  if  no 
activity  exists  on  the  c onmun i c a t i ons  line  for  sixty  (60) 
seconds;  the  I-S/A  AMPE  shall  generate  a  truncate  indication; 
insert  an  EGh;  and  forijard  tne  CRITIC  The  1-3/A  Af^'PE  shall 
notify  the  input  terminal  that  the  CRITIC  has  been  truncated 
and  for^uarded  incompete.  The  service  operator  shall  be 

alerted  of  the  notification  with  a  unique  visual  and  audible 
alarm 

3.12.  3.  7,  2.  The  I-S/A  AtdPE  shall  detect  and  resolve 
receipt  of  unpaired  ECN  bit  sequences  The  I-S/A  AiTPE  shall 
insert  an  ECN  if  a  second  SChl  ia  detected  without  an  intervening 
ESN  The  I-S/A  AMPE  shall  continue  processing  the  CRITIC  and 

notify  the  service  operator  uith  a  unique  visual  and  audible 
alarm. 

3.12.3.7.4.  The  I-S/A  At'PE 
and  ECM  sequences.  However.  if 
I-3;'.A  ArtPE  shall  continue  processing 
the  service  operator  of  the  error. 

3.12.  3.7  5,  The  I-S/A  AHPE  s 
(exceedin.g  5400  cha-acters)  0 
me  1  cation,  insert  an  ECN.  continue 
notify  the  service  operator 
audible  alaT'.n  and  the  originati 
ici  e  s  3  a  g  e 

3.12.3  3  The  shell 

C  R  I  -  I  C  •  4  .V ;  t  .1  1  c  w  o  r  i  “  u  t  e  s  -  ~ 

3.12.'^-  CSSCS  lies  sag  as 

3.  IP.  A  i  .j  1-3  A  C.--FE  shall 

D  e  s  1  g  n  a  t  0  r  (CD)  to  os  t  a  c  o  -  r  e  :  t  CD 
U  h  e  n  an  :  .  3  i  ;  p  CZ  :  s  d  t  a  •;  t  a  0  <  the  I  -  £ .  A 

croeer  ID.  con  ti-'^e  to  process  the  r.essage,  :s-r-ace 


.■  a  r  i  .-  g  Channel 

-or  T"a  -.-■■z  z--.r  1  lo-e 
TAr  i-5i :  i-?ert  t-e 


■-11  detect  an  overlength 

-  “IC;  generate  a  truncate 
r'ocessing  the  IRITIC.  and 

-  .'h  a  unique  visual  and 
r  terminal  via  a  service 


shall  cneck  for  the  SCM 
sn  error  is  detected,  the 
the  CRITIC  and  notify 
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service  message  to  the  input  terminal  and  notify  the  service 
operator. 

3.12.  4  2.  The  I-S/A  AMPE  shall  verify  the  Channel 
Sequence  Number  (CSN)  to  be  valid  and  in  the  proper 
sequence.  The  I-S/A  AMFE  shall  send  a  ZFX  as  described  in  DOI-103 
to  the  input  terminal  when  an  out  of  sequence  CSN  is 
detected  and  continue  to  process  the  message  If  an  otherwise 
invalid  CSN  is  detected,  the  I-S/A  AMPE  shall  record  the 
message  as  the  last  good  CSN  received,  continue  processing,  and 
notify  the  service  operator  and  the  input  terminal. 

3.12.  4. 3  Upon  recognition  of  two  consecutive  SOM's 
without  an  intervening  ECM,  the  I-S/A  AMPE  shall  deliver  all 
data  preceding  the  second  SOM  to  the  error  correction 
console  for  manual  inspection  and  correction.  The  second  SQM 
shall  then  be  treated  as  the  beginning  of  a  new  transaction. 

3.12.  I-S/A  AMPE  shall  recogniie  a  DSSC3  message 
by  the  presence  of  'V'  Routing  Indicators  (RI),  i.e  ,  RI's 
that  begin  with  the  letter  in  F/L  2  of  the  message 

3.12.  4  5.  The  I-S/A  AMPE  shall  separate  DSSC3  messages  on 
tne  basis  of  valid  SOM  and  ECM  sequences.  The  I-S/A  AMPE  shall 
perform  the  straggler  checks  described  in  DO  I- 102  and  DOD 
Directive  C-5030.  5S-M. 

3.12.  4  s  The  1-3 /A  AMPE  shall  detect  an  ECM  seauence  and 
Station  Serial  Number  mismatch,  reject  the  message  and  notify 
the  input  ter.minal  and  the  I-3/.A  AMPE  operator 

3.12.  -i  7  The  1-3/A  AMPE  shall  detsct  an  o\erlength 
■nessage,  generate  a  truncate  •ndication,  insert  an  ECi'!, 
c  c  n  •:  1  n  u  e  ?  ~  o  c  e  s  s  i  g  the  message,  and  n  o  1 1  ~  y  t  *  e  service  o  o  e  -  a  t  o  r 
and  Che  originating  terminal  via  a  s  e  r  .  i c  e  message 

3.12. *!  3  t'^'e  I— o  f*  AMP c.  snali  detect  an  idie  line 
condition  once  a  valid  transaction  has  begun.  Ir  no  activity 
occurs  on  the  lire  for  -S)  minutes.  the  1-3/A  shall 
r.  0  1 1  r  y  the  service  o  ?  e  -  a  t  o  - 
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3.12.  A.  9.  Following  is  an  EXAMPLE  of  tha  format  linos  to  be 
validated  in  in  a  DO I- 103  message  and  validation  checks  that  the 
1-3/A  AMPE  shall  perform: 

FORMAT  LINE  2  PTTMZYUU  YYOSR I  123-1  1234567-MNSH — YYCEST  YADEST 

FORMAT  Llt-IE  4  2NY  MMNEH<;> 

FORMAT  LINE  15  ^1234 

FORMAT  LINE  lo  ;>  =======t-4j|N;M 

3.12.4.10,  FORMAT  LINE  1  -  TRANSMISSION  IDENTIFIER  (TI) 

LINE. 

3.12.F.  10.  1  For  DSSCS  MODE  I  terminals;  the  use  of 

the  TI  13  optional. 

3.12.4.10.2.  For  those  terminals  using  TI  lines#  the 

following  rules  apply. 

3.12.  4  10.  2,  1. 

TI  Line  and  all  MODE 
roll  0 ws : 

3.12.  F  10,2.2.  The  first  four  characters  are  "ZCZC". 

3.12.410  2.3.  The  fifth;  sixth  ard  seventh  characters 
are  the  Channel  Designator  (CD'-.  It  must  match  the  CD  stored 
in  the  1-3.  A  AMPE  for  that  channel. 

3 . 12 .  F,  10.  2.  4.  The  eighth  character  is  a  figure  shift  if 
the  terminal  operates  in  the  ITA-2  code. 

next  three  c  n  a  r  a  c  s  e  r  s  are  the 
■■  A  1 2  r  j  15  :  ;  r  a  : ,  j  e  r  ?  i  in  e  r  ''  c  r  if 

1  -*  1  *1  IS  n  0  V  1 .1  e  next  x  p  -e  c  i  ss  d  w  3  il. 

3.12.  -1  ID  2  b  The  12tn  character  is  a  letter  function 
if  the  terminal  e  p  e  r  3  ^  s  in  r  h  e  I T  a  -  2  .:  c  -t  e . 

3.12.  4  1;  7  DSSCS  •'DDE  I  t-eminais  using  the  the 

a  0  0  r  e  V  1  a  t  e  d  TI  1  1  *■  e  t-e  •-tart  of  -e=:a:e  'ZCZC"  is  a  1 1  r  e  1 a  t  e  d 
•ari  on  iu  one  I"  is  gene'atei  anc  a  ant  -0  o.-e  I-S  A  a,“F3  The 

or  .  i.'.'-p'  1,5  Ecan'?  i5 


For  DSSCS  MODE  I  terminals  using  a  full 
II  and  MODE  V  terminals#  the  TI  line  is  as 
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3.12.4.10.2  thru  3.12.4.10.2.6. 

3.12.4  10.2.8.  An(j  error  in  Format  Line  i  will  not 
result  in  the  message  being  rejected/  except  for  duplicate  CSN. 

3.12.  /I  11.  FORMAT  LINE  2  contains  the  following' 

3.12.4,  11  1  FIELD  1  IS  the  precedence.  Only  FLASH/ 
ir"r''ED  I  ATE/  PRIORITY  and  ROUTINE  are  authorized.  Any  invalid 
character  will  reg.uire  the  I -3 /A  AMPE  to  process  the  message 
at  IMMEDIATE  precedence/  but  leave  the  character  as  received. 

3.12.4  11.2.  FIELD  2  and  3  are  the  Language  Media  Format 
(LMF).  The  following  LMF's  are  authorized  in  DSSCS/  A/  3/  C/ 

D/  E/  0/  Hi  Ii  R/  T  and  Y.  Any  character/  other  than  these 
listed/  will  result  in  the  message  being  rejected, 

3.12."+  11.2.1.  ■^.le  first  LMF  character  is  the  input 

station  media  of  transmission.  The  second  LMF  character  is 
the  preferred  output  LMF. 

3.12.4  11  2  2.  The  LMF's  of  Ei  H/  and  R  can  only  be 
■paired  with  A,.  Ci  and  T  respectively/  and  the  LMF's  of  B/ 

Di  and  I  can  only  be  paired  with  themsel'^es  Any  unauthorized 
pai-ing  will  result  in  the  message  being  rejected 

3.12.4  11.2,  3.  The  LMF's  of  "Q"  and  "Y"  are  generated  salA 

by  the  I-E-A  AM»E.  The  LMF's  of  "OT"  and  "YT"  indicates  that 

the  I-S.’’A  preformed  format  conversion  on  the  message. 

3.12.  F.  11  2  “lELD  4  IE  the  DSSCS  s-ecu-i-u  sentinel  "M". 

If  there  is  a  ^  y  o  t  .t  e  r  ■:  h  a  ~  a  c  t  ?  r  in  t  .••  i  s  - :  e  !  d  ■  1 1  e  m.  e  =  =  a  -g  a  'will 

be  rejected 

3.12.0.  11  .1  rIZ_D'S  1'  thr-j  S  are  the  Conte.nt  Indicator 
Coze  (  C  1 1  ;  "h  -  ?  f  c  u  z  h  a  a  c  t  e  *■  C  I C  :  e  1  d  t  s  1  s  o  called  the 

:  G  m.'m  u  n  1  0  a  1 1  e  r  s  a  :  1 1  .o  n  i  d  n  1 1  f  ;  e  r  field  w  -■  e  r  it  contains 

0  0 m r, u n  i  c  1 1  o n  5  i  r  s  t  ”  u  c  t :  :  n s  )  contains  i  n  r  :> -r- m a  i  o n  related  to 

the  t'jp.e  of  me  i  sate  cez"g  p'-ccesiec  T- -?  C I  2  is  validsted  to 

c  a  e  ;  t  "•  e  r  r  j  _r-  a  1  c  ■'  a  1 1  i  c  *  "  t  n  •  z-  e  s  1  o  h  a  t  •:  1 1  ;  a  r  d  .ore  numeric 


j  W  ■  •  y  ^  y  ■ 


t 


fr.-. 


r*< 

L'  ,' 


JM 

-*  ’ 


• ,  • . 
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3.12.  4.  11.  4  1.  If  t^e  message  has  a  SEL  "A"<  indicating 
preparation  in  ITA-2  paper  tape/  and  the  CIC  contains  a  numeric 
character  in  the  fourth  character  position/  the  appropriate  shift 
characters  must  precede  and  follou  the  character.  If  the  shift 
functions  are  not  present/  the  message  uili  be  rejected 

3.12.  11-  5.  FIEuD  9  is  a  space.  If  not  present;  the 

message  must  be  rejected. 

3.12.  FIELDS  10  thru  la  are  the  Originating 

Station  Routing  Indicator  (QSRI).  On  DSSCS  messages;  the  OSR I 
must  start  uith  the  letter  '‘Y"  and  are  six  characters  long 

However;  a  seventh  cnaracter  may  he  added  to  indicate  Vj 

All  characters  must  be 


alphabetic. 


or 


;e  message  is  rejected 


SIX 


character 


OSR  I  is  used;  then  the  seventh  position  must  be  a  space;  or  the 
message  willberejected 

3.12.4.  11.7.  FIELDS  17  thru  20  are  the  Station  Serial 
Number  <SSN'.  If  the  station  is  operating  in  the  ITA-2  code; 
then  the  S5N  must  be  p-"eceeded  by  a  Figure  (upper  case)  function. 
The  SSN  must  be  all  numbers  or  the  message  is  rejected.  The 
SSN  also  is  used  as  the  End  of  Message  (EDM.'  validation  number  in 
message  format  line  15. 


3.12.4.  11.8 
■ejected. 


P  1  SL'—U'  c.  i 


1  s 


space;  or  the  message  is 


3.12.  ^  11.9.  FIELDS  22  thru  22  are  the  Time-of-File  (TOF). 
This  field  must  be  =11  numbers  More  then  or  less  than  seven 
numbers;  or  alohaoetic  characters  will  result  in  the  message 
oeing  rejected. 


3.12.  ^  i  5 

sta^t  of  the  security  fieia 
b  e 


dash  <  -  )  'jj  h  1  ■:  h  indicates 


the 


If  not 


0  r  e  s  e  n  1 


the  message  wi 


1  1  1 


3.12.4  11.  11. 
position  DC'  .ru  s  t 
tne  message  is  ••  _ 

'■■r'an  smi  s  s  i  on  Cont-ol  Cede  (-CC'  The 

information  contained  in  message  -format  line 


I  ELDS  DC  thru  52  are  the  security 
DSSCS  security  sentinel  of 
1  tr~ouQ.h  23 


t  e  :  ©  F  D  3  1  1 1  0  n 


field. 
■M";  or 
i  the 


-e  d 


^  om 
the 


(j) 

For  stations  operating  in  ITA  Code,  Position  30  must  be  preceeded  by  a 
letters  (lov;er  case)  function. 
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c  1  a s s  1  f  1  ca 1 1  on ,  codeujordi  caveats/  and  other  data  appearing  in 

message  Format  Line  12, 

3.12.  4  11.  11.  1.  The  I-S/A  AMFE  must  validate  that  the 
TCC  in  message  format  lines  2  and  4  matcn  and  are  valid.  Any 
error  uill  result  in  the  message  being  rejected. 

3.12.  *’  FISlC'S  34  and  25  are  2  dashes  ( — )/  aihich 

indicates  the  start  of  routing.  Any  invalid  character  or  less 
’ihan  tuo  dashes  uill  result  in  the  message  oeing  rejected  If  a  Station  operate 
in  the  !TA-2  Code,  t^ie  two  dashes  must  be  preceeded  by  a  figures  (upper  case)  function  and  followe 
3.12.4  11.13  FIELD  3±  is  the  start  of  routing.  All  DSSC3  by  a  lette 

FI's  must  start  uiitn  the  letter  'V"/  or  the  message  is  rejected,  (lower  caS6 
D3SCS  FI's  are  six  .etters.  but  there  can  be  a  seventh  letter.  function. 
Each  PI  IS  separated  by  a  space/  or  the  message  is  rejected  A 
m^^xi.Tium  of  4  RIs  will  appear  on  the  first  line  of  Format  Line 
2/  with  a  maximum  of  9  routing  indxcators  on  each 

successive  line.  A  maximum  of  500  RI's  are  authorized  on  a 
DSSC5  message  If  a  message  exceeds  500  RI'S/  the  message 
IS  rejected.  The  message  will  be  rejected  if  RI's  are  split 
across  a  line/  such  as  the  first  3  character  on  one  line  then 
end  of  line  functions  followed  by  the  remainder  of  the  RI.  If  any 
routing  indicator  begins  with  any  character  other  then  a  V,  the 
entire  message  must  be  rejected  and  none  of  the  remaining  or 
valid  .-outing  indicators  are  processed^  A  period  (.)  will 
be  inrC!--, c-d  foiiowing  the  last  addressee's  PI  to  indicate  end- 
of  -  r  ou  1 1  ng /A  I  f  the  Station  is  operating  in  the  ITA-2  Code  the  period  (.)  must  be 
ceeded  by  a  figure  (upper  case)  function  and  should  tj  followed  by  a  letters  (lower  case)  func?ioi 

A.  12.  FCRt'IAT  line  4.  SECURITY  LINE 


The 


r  9  j  c  V  3  0  .  0  1  1  w  '.ii  i  ‘7.  ”  9 

■'Nil"/  a--,  y  other  charaote- 

.message  d  e  i  n  -g  r  e  j  e  c  t  e  s 
t  r  a  n  -  .n  1  a  5  1  'C-  r.  o  n  t  r  o  *  u  o  .i  e 


'U  s  ' 


N*  9  5  £  s  ^  9 


fi”St  t.hree  characters  are  the 
■"g  signal  Cn  DSSCS  messa.ges  this 
u  d  1  n  .g  u  n  •:  1  a  s  5  1  f  :  e  d  and  u  n  c  1  a  s  s  i  f  :  e  d 
t.he  secu-ity  warning  operationg 
pace  cha-acter  -cr  tae  message  is 
space  IS  the  DSSC.3  security  sentinel 
■or  only  one  ’M"  uill  result  in  the 
Foiiowing  the  '."’rv  is  toe  DSSCS 
TCCi.  Tne  TCC 5  in  Fermat  Line  2  and  4 
15  rejected 
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3.12.  4.  13.  FORMAT  LINE  15 

3.12.4.  13  1.  This  line  has  two  separate  functions  Each 
function  must  be  on  a  line  by  itself  The  first  iine<s)  is  the 

correction  line.  (If  used)  it  must  contain  the  prosign  "C" 

followed  by  necessary  corrections.)  On  the  last  line  is  the 
End  Of  Message  ( EOM)  validation.  It  contains  a  number  symbol 
(=)  immediately  followed  by  the  four  digit  station  serial 
number  which  appeared  in  format  line  2<  positions  17  thru  20.  If 
number  symbol  missing;  there  is  less  then  four  numbers^ 

or  the  EOM  validation  numoers  do  not  match  the  SEN  in  message 
format  line  2,  the  message  is  rejected  If  the  station  is  operating  in  the  IT 
Code,  the  numbers  symbol  (-)  is  proceeded  by  a  figures  (upper  case)  function  and  the  last  .number 
-.i.2.  14.  Format  line  Iw,  End  of  Message  (EOM). the  four  digit  number  is 

followed  by  a  letters  (1 

3.12.4.  14  1  The  EDM  functions  are  "2  carriage  returns  c'Se)  fun 
(CR)i  S  line  feeds  (LF)  and  4  N'S(  e.  g  ,  I===  =  ====N.NNN" .  To 

allow  for  errors  in  the  nuinber  of  ’line  feeds<  the  I-S/A  AMPE 
shall  accept  as  a  nini.-nur.  2  line  feeds  and  4  N'. 

3.12.  4  15.  Following  is  an  EXAMPLE  of  an  D0I-i03  SPECIAL 
formatted  message  and  the  format  validation  checks  that  the 
I-S/A  AMPE  shall  perform. 

FORMAT  LIf>iE  1 
FORMAT  Lir.E  2 
FORMAT  LliJE  3 
FORMAT  LIf-iE  4 
FORMAT  LINE  15 
FORMAT  line  16 

3.12.4  15  1  Format  line  1  -  See  paragraph  3.12,4.10. 

3.12.4  15  2  For-'st  L:-e  2  -  Contains  rhe  dual  precedence 

prosign  and  the  destination  routing  indicatOT-s 

3.12.4.  15  3  .-or mar  iir, .=  3  -  Contains  the  prosign  DE- 

the  originating  stations  routing  indicator,  the  station  serial 

numbe"  o  receded  bu  a  hatch  '".ark,  and  the  rile  time  of  the 


2CZCA2C 123 
FP  yVDEST  y'CE3T.:<> 

DE  YYQSPI  si234  1231547.;;:  = 
ZNY  MMN3H.:;= 

41234 

.;:..:;======r==rjriNN 
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3.12.  4  15.  4.  Format  line  4  -  See  paragraph  3.12.4.12. 

3.12.  4.  15.  5.  Format  line  15  -  See  paragraph  3.12.4.13. 

3.12.  4.  15.6.  Format  line  16  -  See  paragraph  3.12.4.14. 

3.12.5  DD-173  JOINT  MESSAGE  FORM  DATA 

3.12.  5.  1.  The  I-S/A  ANPE  shall  recognize  DD-173 

transactions  fro.''i  various  input  devices/  i.e./  optical 

character  readers/  kegtoard/ display  devices  ^cathode  ray  tubes, 
etc  )  The  I-S/''A  ANPE  shall  recognize  a  DD-173  transaction 
that  contains  pne  or  more  pages.  The  I-S/A  AMPE  shall 

validate  the  precedence,  classification,  a  Message  ID.  a  page 

number,  and  on  the  last  page  of  the  message  the  total  number  of 

pages.  The  I-S/A  .AMFE  shall  detect  th_£._start  of  the  DD-173 
message  as  a  function  of  the  line  control  procedures  for  the 
input  line. 

3.12.  5  2.  The  I-S/A  AM^^E  shall  check  the  page  number  and 

Message  ID  of  each  incoming  DD-173  form.  If  the  Message  ID 
field  IS  missing  or  invalid  (improper)  alphanumeric  format, 
inconsistent  across  pages.  etc.  ).  precedence  character 

missing  or  invalid,  classification  missing  or  invalid.  or  if 
the  page  numjer  number  is  in  error  (i.  e.  .  missing-  non- 

numeric.  out  of  seq.uence.  etc,  ).  the  I-S/A  AMPE  shall  route  the 
message  to  the  service  operator  For  messages  delivered  to 
the  service  operator,  that  are  Flash  precedence  or  above.  rhe 
I-3/.A  AMPE  shall  alert  tne  service  operator  with  a  visual 
ano  audible  alarm 

3.12,  5  3.  The  r-S/A  AMPE  s  a  1  1  detect  an  lale  line 

condition  once  a  valid  t  r  .s  n  s  a  c  1 1  c  "■  h  .a  s  begun  If  no  activity 

occurs  on  the  line  for  a  three  (3)  minutes,  the  I-S..A  AMPE  shall 
noti-y  the  service  operator. 
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UNCLASSIFIED 


3.126.  1.  The  I-S/A  AMPE  shall  recognize  Abbreviated 
Message  Forirat  (AM.F)  transactions  bg  the  presence  of 

"QGGQ"  in  line  2  in  positions  1  through  4  The  I-S/A  AMPE 
shall  guard  against  interlaced  messages  by  checking  for 

duplicate  ''GQGG"  (NGTE.  "GGQG"  also  indicates  end  of 

classification  line).  If  an  error  is  detected-  the  I-S/A  AMPE 

shall  deliver  the  message  to  the  service  operator. 

EXAMPLE: 

FORMAT  line  1  2CZCASC123 
FORMAT  LINE  2  GQQG 
STUTTER  LINE  GQGG 

FORMAT  LINE  16  NNNN 

3.12.^  2.  The  I-S/A  AMPE  snail  separate  AMF  messages  on  the 
basis  of  valid  SOM  and  ECM  sequences. 

3.12.6.3.  The  I-S/A  AMPE  shall  detect  the  following  error 
conditions  and  process  them  as  described  above  For  DSS 
messages  (see  p a-a g r a p h  3 . 12 .4  .  lo f  this  appendix):  Overleng 

messages.  Channel  Designator  iCD)  errors.  Channel  Sequence  Number 
‘CSN)  errors,  and  Idle  line  conditions. 
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4.0  JAMAP  128  Message  Processing  Requirements. 


4.1  General  Cements. 


4.1.1.  This  section  details  existing  JAMAP  1  ?8  fomat  validation 
processing.  The  checks  and  validations  currently  perfomed  and 
identified  herein  shall  be  performed  by  the  I -S/A  AMPE  in  such  a 
manner  that  subscribers  are  provided  the  sane  service  on  an 
interface  and  interaction  basis  that  they  currently  derive  from 
existing  ASCs  and  Service/Agency  AMPEs. 

4.1.2.  There  are  two  categories  of  JANAP  format  header  - 
"teletypewriter"  which  is  used  with  that  input  medium  and  "data 
pattern"  which  is  used  with  all  other  media.  The  differences,  where 
existing,  will  be  described  in  this  section. 

4.2.  Val idation/Veri fication  Requirements 


4.2.1.  Format  Line  1  -  Transmission  Identifier  (TI)  Line.  I-S/A 
AMPE  validation  of  the  TI  line  shall  be  identical  for  both 
asynchronous  channels  (Mode  II  and  V  teletypewriter  terminals  \/hose 
use  of  a  TI  line  is  mandatory)  and  synchronous  channels  (Mode  I 
users  who  employ  line  block  framing  and  whose  use  of  a  TI  line  is 
optional,  but  must  be  specified  at  the  time  the  I-S/A  AMPE  sets  the 
port/Channel  parameters).  All  TI  lines  through  the  CD-CSM  fields 
shall  be  processed  as  follows: 

4. 2. 1.1.  The  first  characters  of  the  TI  line  block  must  be  a  Start 
of  Header  (SOH)  and  a  select  (SEL)  character.  If  the  channel  is 
asynchronous,  these  shall  have  been  inserted  by  the  I-S/A  AMPE;  if 
the  channel  is  synchronous,  the  terminal  has  inserted  them. 

4. 2. 1.2.  Check  1.1. a.  The  first  data  characters  of  the  TI  line 
must  be  a  val id  Start  of  Flessage  Sequence  (SOMS). 

Error  Condition  -  Hone  -  nothing  can  be  recognized 
prior  to  receipt  of  the  SOH. 

Error  Resolution  -  H/A 

4. 2. 1.3.  Check  1.1. b.  The  next  three  characters  of  the  TI  line 
must  be  the  Channel  Designator  (CD)  and  must  match  the  CD  stored  at 
the  I-S/A  AMPE  for  that  port/channel . 

Error  Condition  -  A  CD  shall  be  considered  to  be  in 
error  if  it  does  not  match  the  CD  stored  in  the  I-S/A  AMPE  for  its' 
associated  channel . 

Error  Resolution  -  Except  for  messages  of  ECP  or  Flash 
precedence,  messages  "ha vTng  TTTJ  errors  shall  be  rejected  to  the  input 
port/channel.  Precedence  categories  are  explained  later  in  this 
document. 
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4. 2. 1.4.  Check  1.1. c.  The  next  character  of  the  TI  line  can  be 
either  a  figures  shift  or  the  first  character  of  the  CSN  field;  the 
figures  shift  must  be  present  for  "A"  Select  (ITA  2)  messages  and 
may  or  may  not  be  present  for  other  selects.  If  the  CSN  Is  correct, 
TI  line  processing  Is  complete  at  this  point. 

Error  Condition  -  A  CSN  shall  considered  to  be  In 
error  If  It  Is  either  non-numeric  or  If  It  Is  not  the  next  expected 
CSN;  l.e.,  one  greater  than  the  last  "accepted"  from  a  Mode  V 
port/channel  or  "received"  from  a  Mode  I  or  II  port/channel.  For 
this  purpose,  a  CSN  of  000  shall  be  considered  to  be  one  greater 
than  999. 

Error  Resolution  -  Messages  of  ECP  or  Flash  precedence 
shall  be  accepted  regardless  of  CSN  errors  detected.  Other  messages 
having  CSN  errors  shall  be  processed  as  follows: 

If  the  CSN  Is  a  duplicate  of  the  last  "accepted" 
(Mode  V)  or  "received"  (Mode  l/Il),  the  message  shall  be  rejected  to 
the  Input  port/channel.  This  Is  the  only  Instance  of  CSN  error 
where  a  message  shall  be  rejected  by  the  I-S/A  AMPE  which  shall 
generate  an  "INVALID  CSN”  message  to  the  Input  port/channel  and  log 
the  error  condition  for  future  compilations  such  as  the  existing 
Communications  Improvement  Memorandum  (CIM)  program.  If  the  CSN  is 
incorrect  for  any  other  reason  including  being  non-numeric,  the 
message  shall  be  accepted.  However,  these  errors  shall  cause  the 
I-S/A  <LMPE  to  generate  a  service  message  to  the  input  port/channel 
citing  the  CD  and  CSN  as  well  as  other  pertinent  message 
identification  data.  This  service  message  shall  indicate  "INVALID 
CD",  "INVALID  CSN"  and  whether  the  message  was  accepted  or 
rejected.  A  duplicate  CSN  shall  cause  generation  of  an  additional 
service  message,  "DUPE  CSN".  When  a  CSN  is  received  out  of 
seque.rice,  an  open  number  (ZFX)  service  message  shall  be  generated  to 
the  input  port  or  channel  detailing  the  missing  CSNs. 

4. 2. 1.5.  Further  I-S/A  AMPE  TI  Line  processing.  To  maintain 
CSN  continuity  between  the  I-S/A  AflPE  and  the  terminal,  the  I-S/A 
AMPE  tables  shall  be  updated  based  on  the  results  of  CSN  and  message 
processing.  When  a  CSN  is  rejected  (i.e.,  duplicate  condition),  no 
CSN'  updating  shall  be  performed.  When  a  CSN  is  accepted,  even  if  it 
is  out  of  sequence,  the  accepted  CSN  (or  the  expected  CSN,  if  the 
received  CSN  is  non-numeric)  shall  be  made  the  last  accepted  CSN  for 
processing  of  future  messages.  When  the  channel  is  Mode  I  or  Mode 
II,  this  update  shall  be  done  immediately  on  receipt  of  the  TI  line 
whether  the  associated  message  is  accepted  or  not,  since  the  Mode  I 
or  Mode  II  terminal  is  assumed  to  update  the  CSN  at  the  beginning  of 
each  message  transmission.  This  is  also  consistent  with  a  terminal 
transmitting  a  tape  in  which  there  are  pre-cut  CSN's  preceding  each 
message.  Since  Mode  V  procedures  require  that  CSN's  be  updated  on 
acceptance  of  the  message.  Mode  V  terminal  equipment  does  not  update 
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Its  TI  generator  until  the  associated  message  has  been  acknowledged 
by  the  I-S/A  AMPE.  Consequently,  the  I-S/A  AMPE  also  shall  not 
update  the  last  accepted  CSN  on  a  Mode  V  channel  until  the  message 
has  been  validated  and  accepted,  and  the  ACK  for  the  message  has 
been  sent  to  the  terminal. 

4.3.  Format  Line  2  -  Message  Header.  For  I-S/A  AMPE 
validation/ verification  purposes,  the  JANAP  header  shall  be  divided 
into  three  parts:  Header  data  up  to  and  including  the 
Start-of-Routlng  Sequence  (Format  Line  2);  the  Routing  Indicator 
Field  (still  a  part  of  Format  Line  2);  and  the  Security  Line  (Format 
Line  4). 


4.3.1.  Header  Validation /Verification  Through  the  Start-of-Routlng. 

4. 3. 1.1.  Precedence  Field.  The  first  header  field  to  be  validated 
shall  be  the  precedence  field.  It  should  be  noted  that  even  though 
the  TI  line  is  the  first  data  received  from  the  port/channel ,  it 
shall  not  be  the  first  message  area  to  be  processed.  The  precedence 
field  shall  be  processed  first  since  the  precedence  of  the  message 
affects  the  decision  on  whether  to  accept  a  TI  line  with  errored 
fields.  Once  validated,  the  precedence  shall  be  saved  for  later 
correlation  with  FL5  precedence(s) . 

4. 3. 1.1.1.  Check  2.1. a.  Precedence  is  a  single  character,  the 
first  character  of  the  header  and  shall  be  validated  to  be  one  of 
five  characters: 

"Y"  -  Emergency  Command  Precedence  (ECP)  which  may  be 
input  only  on  authorized  ports/channels. 

"2"  -  Flash 

"0"  -  Immediate 

"P"  -  Priority 

"R"  -  Routine 

Error  Condition  -  If  the  field  is  not  one  of  the  five 
precedence  characters  specified  above  or  ”Y”  is  received  from  a 
port/channel  not  authorized  its  use. 

Error  Resolution  -  An  error  in  the  precedence  field  of 
either  an  invalid  or  an  unauthorized  character  shall  result  in 
message  rejection  on  all  except  Mode  II  channels  where  the  invalid 
precedence  character  shall  be  replaced  by  an  '0"  (immediate)  and  the 
message  processed  at  that  precedence  level.  Errors  in  the 
precedence  field  which  cause  rejection  shall  result  in  generation  of 
an  "IN'^/ALID  HEADER"  error  condition  except  for  attempted  use  of  ECP 
by  an  unauthorized  user,  which  shall  cause  generation  of  a  separate 
"UNAUTHORIZED  USE  OF  ECP"  error  condition. 

4. 3. 1.2.  language  Media  Format  (^F).  The  next  field  to  be 

validated  in  a  JAN'AP  format  message  shall  be  the  Language  and  Media 


Format  (LMF)  field.  This  is  a  two  character  field  in  which  the 
first  character  (LMFl)  indicates  the  medium  in  which  the  input 
message  was  originally  prepared.  It  is  sometimes  also  called  the 
Input  LMF  or  ILMF.  The  ILMF  must  be  consistent  with  the  select 
character  (SEL).  The  second  character  (LMF2)  Indicates  the  medium 
in  which  the  originator  prefers  the  message  to  be  delivered  to  the 
addressee.  It  is  sometimes  also  referred  to  as  the  Output  LMF 
(OLMF)  or  Preferred  Output  LMF  (POLMF).  Input  header  processing 
merely  validates  the  SEL/LMF  combination. 

4. 3. 1.2.1.  Check  2. 2. a.  In  the  I-S/A  AMPE,  the  LMF  pair  shall 
never  be  validated  separately.  LMF  Validation  shall  always  be 
combined  with  validation  of  the  SEL,  and  the  three  characters  shall 
be  validated  together.  If  the  message  is  from  a  TI  user,  the  SEL 
shall  be  obtained  from  the  second  framing  character  of  the  TI  line 
block.  Otherwise,  it  shall  be  obtained  from  the  second  framing 
character  of  the  header  line  block.  Once  the  SEL-LMF  combination 
passes  validation,  the  LMF  pair  information  shall  be  saved  to 
determine  whether  a  message  of  the  specified  LMF  can  be  delivered  to 
a  given  RI . 

Error  Condition  -  If  the  SEL/LMF  combination  does  not 
match  any  I-S/A  AMPE  table  entry,  the  SEL  shall  be  validated 
separately. 

Error  Resolution  -  If  the  SEL  is  invalid,  an  error 
condition  shall  be  recorded  and  the  message  shall  be  rejected  with 
no  exceptions.  A  "REPROTECT  TO  ALL  ADDRESSEES”  service  message 
shall  be  generated. 

If  the  message  is  high-precedence  (Cat  1)  and  not 
magnetic  tape,  the  LMF  field  shall  be  corrected  to  make  the  invalid 
LMF(s)  the  most  common  ones  for  that  SEL  ("T"  for  "A"  Select,  "A" 
for  "H"  Select,  "C"  for  "D"  Select).  If  LMFl  is  valid  and  is  "H", 
"E",  or  "R",  an  invalid  LMF2  shall  be  made.  "C” ,  "A",  or  "T" 
respectively. 

When  the  SEL  is  valid,  but  one  of  the  LMF  characters 
is  invalid,  a  test  shall  be  made  of  the  message  precedence  and  of 
the  SEL.  If  the  message  has  a  SEL  of  "3”  or  "C"  (magnetic  tape),  or 
is  of  low  precedence,  it  shall  be  rejected,  with  an  "IlTv'ALID  HEADER” 
service  message  being  generated. 

4. 3. 1.3.  Sl^^le  Security  Character  Field.  The  next  field  to  be 

validated  shall  be  the  single  character  security  field.  The  single 
character  which  indicates  the  security,  shall  be  one  of  the 
following  characters: 

”T”  -  Top  Secret 
”S”  -  Secret 
”C”  -  Confidential 
”R”  -  Restricted 


27 


"E"  -  Unclas  E  F  T  0  -(pncrypt  for  transmission 
only) 

"U"  -  Unclas 

A  single  card  message  (LMF  of  SC)  is  only  authorized  a  security 
level  of  unclassified  and  this  field  shall  be  validated  to  be  a  "U". 

4. 3. 1.3.1.  Check  2. 3. a.  The  single  character  shall  be  compared 
to  the  valid  security  characters  above. 

Error  Condit ion  -  Detection  of  an  invalid  security 

character . 


Error  Resolution  -  An  error  shall  cause  rejection, 
with  generation  of  an  "INVALID  SECURITY  FIELD  -  SEC"  service 
message.  There  shall  be  no  exceptions. 

4. 3. 1.3. 2.  Check  2.3.b.  The  security  of  the  message  as  indicated 
by  this  character,  shall  also  be  tested  against  the  security  of  the 
channel  over  which  the  message  is  being  received. 

Error  Condition  -  If  the  message  security  is  higher 
than  the  channel  security,  the  message  is  in  error. 

Error  Resolution  -  The  message  shall  be  rejected  as 
above  for  security  error.  There  shall  be  no  exceptions. 

4. 3. 1.4.  Content  Indicator  Code  (CIC)  _Fif^ld.  The  four 

character  CIC  field  (also  called  the  Communications  Action 
Identifier  field  when  it  contains  communications  instructions) 
contains  information  related  to  the  type  of  message  being 
processed.  See  Appendix  19A  for  specific  additional  codes  and 
required  action. 

4. 3. 1.4.1.  Check  2. 4. a.  If  the  message  has  a  SEL  of  "A", 
indicating  preparation  in  ITA2  paper  tape,  and  the  CIC  contains  a 
numeric  character  in  the  fourth  character  position,  the  appropriate 
shift  characters  must  precede  (SO/FIGS)  and  immediately  follow 
(SI/LTRS)  that  character. 

Error  Condition  -  Absence  of  the  necessary  shifts 
indicates  that  the  message  preparation  medium  does  not  conform  to 
the  select  character. 

Error-,  Resolut  ion  -  The  message  shall  be  rejected  for 
"INVALID  HEADER;"  thpre  shall  be  no  exceptions  in  this  case. 

4. 3. 1.4. 2.  Chec^_2.4.b.  The  CIC  shall  be  validated  to  be  either 
four  alphabetic  or  three  alphabetic  and  one  numeric  characters. 

Error  Condition  -  N'umeric  character(s)  in  other  than 
the  fourth  character  position. 
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Error  Resolution  -  Low  precedence  messages  shall  be 
rejected.  Errors  in  the  CIC  field,  such  as  numeric  characters  in 
the  first  three  characters  with  other  than  an  "A"  select,  shall  be 
accepted  if  the  message  is  high  precedence  (CAT  I).  When  a 
high-precedence  message  is  accepted  with  CIC  field  errors,  the  CIC 
field  shall  be  changed  to  "WVWW."  This  shall  be  be  transmitted  to 
the  receiving  terminal  in  lieu  of  the  original  errored  CIC  field. 

4. 3. 1.4. 3.  Chj!ck  2.4.c.  Two  special  CIC’s  are  used  to  provide 

special  handling  to  Flash  precedence  Emergency  Action  Messages 
(EAMs).  The  I-S/A  AMPE  shall  check  to  see  if  the  CIC  is  in  this 
category. 

Action  -  Detection  of  these  CIC’s  in  a  Flash  message 
shall  cause  that  message  to  take  precedence  for  delivery  over  other 
Flash  traffic.  These  CIC’s  shall  be  ignored  in  other  than  Flash 
messages . 

4. 3. 1.5.  Separator.  The  character  following  the  CIC  field  must 
be  a  space  (teletypewriter  space,  card  no  punch).  Note  that  if  the 
select  is  ”A"  and  the  fourth  CIC  character  is  numeric,  the  SI/LTR 
shift  must  precede  the  space  separator. 

4. 3. 1.5.1.  Check  2.5.ji.  Check  the  character  following  the  CIC 
field. 

Error  Condition  -  Any  character  other  than  a  space 

character. 

Error  Resolution  -  Any  other  character  shall  cause 
rejection  of  the  message  for  "INVALID  HEADER.”  There  are  no 
exceptions. 

4. 3. 1.6.  Originating  Station  Routing _Ind_icator  (OSRI)  Field. 
Following  the  separator  is  the  seven  character  OSRI  field.  This 
must  be  a  seven  character  RI  in  the  JANAP  format. 

4. 3. 1.6.1.  Check  2. 6. a.  The  OSRI  must  be  a  valid  RI  and 
generally  shall  be  validated  in  the  same  manner  as  a  destination  RI , 
i.e.,  all  characters  must  be  alphabetic;  the  relay  portion  of  the  RI 
(first  four  characters)  must  be  valid;  if  the  relay  portion  is  the 
local  I-S/A  AMPE,  the  next  two  characters  shall  be  checked  for 
validity  and  the  seventh  character  shall  be  verified  to  be  an 
alphabetic  character. 

Error  Condition  -  The  OSRI  is  invalid. 

Error  Resolution  -  Any  error  in  the  OSRI  field  shall 
result  in  message  rejection  for  "liNVALID  HEADER".  There  shall  be  no 
exceptions . 


4. 3. 1.7.  Originating  Station  Serial  Number  (OSSN)  Field. 
Following  the  OSRl  is  the  four-character  OSSN  field.  After  the 
alphabetic  OSRI ,  an  upshift  (SO/FIGS)  is  required  on  "A”  select 
messages  No  upshift  shall  be  allowed  with  other  selects.  The  OSSN 
shall  be  validated  to  be  four  numeric  characters,  and  low  precedence 
messages  which  fail  this  check  rejected  for  "INVALID  HEADER".  Flash 
and  ECP  messages  shall  be  accepted  with  four  non-numeric  characters 
other  than  space  or  hyphen  and/or  a  variable  number  of  shift 
characters.  A  valid  OSSN  shall  be  saved  for  later  comparison  with 
the  Trailer  Station  Serial  Number  (TSSN)  at  the  end  of  the  message 
to  insure  that  a  "straggler"  condition  does  not  exist.  Straggler 
checking  is  described  in  detail  under  End  of  Message  validation. 

4. 3. 1.7.1.  Check  2. 7. a.  Check  "A"  SEL  messages  for  an  upshift 
(SO/FIGS)  after  the  alphabetic  OSRI. 

Error  Conditioi^  -  If  an  upshift  (SO/FIGS)  is  not 
present  on  "A"  select  messages  or  if  an  upshift  is  present  on  any 
other  type  of  message. 

Error  Resolution  -  An  error  shall  cause  message 
rejection  for  "INVALID  HEADER"  with  no  exceptions. 

4. 3. 1.7. 2.  Check  2.7.b.  The  OSSN  shall  be  validated  to  be  four 
numeric  characters. 

Error  Condition  -  The  OSSN  is  not  four  numeric 

characters. 

Error  Resolution  -  When  the  message  is  ECP  or  Flash 
four  non-numeric  characters,  other  than  space  or  hyphen  (dash), 
shall  be  acceptable.  The  detection  of  a  dash  or  a  spare  before  four 
non-shift  characters  are  found  shall  cause  rejection  of  the  message 
for  "IiVi/ALID  HEADER".  When  a  high-precedence  message  is  accepted 
with  an  OSSN  field  containing  non-numeric,  characters,  th*’  OSSN  field 
shall  be  changed  to  "9999."  In  the  case  of  such  acceptable  errors 
in  either  this  field  or  in  the  following  field,  the  fourth  character 
of  the  Content  Indicator  Code  field  shall  be  changed  to  a  "W" 
(provided  the  CIC  field  has  not  already  been  changed  to  4  W's)  to 
indicate  to  the  receiving  terminal  the  acceptance  of  an  errored 
high-precedence  message.  These  corrections  shall  be  used  to 
construct  both  the  output  header  to  a  terminal  and  the  "IN.LALID 
HEADER  ACCEPT"  service  message,  so  that  both  the  delivery  terminal 
and  the  input  terminal  are  aware  of  any  changes  made  in  these  fields 

4. 3. 1.8.  Separator .  A  space  character  separator 
(teletypewriter  space,  card  no  punch)  must  be  present  following  the 
OSSN. 

4. 3. 1.8.1.  Check  2. 8. a.  Check  for  space  character. 

Error  Condition  -  No  space  character  following  the 


Error  Resolution  -  An  error  in  the  separator  field 
shall  result  in  message  rejection  for  "INVALID  HEADER".  There  shall 
be  no  exceptions. 

4. 3. 1.9.  T^e-of-File  (TOE)  Fi^_d.  Validation  of  the  TOF  field 
is  the  same  as  that  for  the  OSSN  field  except  that  a  seven-character 
field  is  involved  rather  than  a  four.  Procedurally ,  the  TOF  field 
is  composed  of  a  three  character  ordi  nal  date  (001-365/366)  and  time 
(0000-2359).  In  a  single  card  (LMF  SC)  message,  the  next  three 
fields  do  not  appear  and  the  TOF  field  is  followed  immediately  by 
the  Start-of-Routing  sentinel. 

4. 3. 1.9.1.  ^heck  2. 9. a.  Check  for  seven  numeric  characters. 

Error  Condition  -  Any  condition  other  than  seven 
numeric  characters. 

Error  Resolution  -  ECP  and  Flash  messages  shall  be 
accepted  and  processed  under  the  same  circumstances  described  in 
OSSN  field  errors  in  paragraph  4. 3. 1.7  and  shall  cause  this  field  to 
be  changed  to  "9999999".  In  all  other  instances,  the  message  shall 
be  rejected  and  an  "INVALID  HEADER"  service  message  generated  to  the 
input  port/channel. 

N^T^:  The  next  two  fields,  4.3.1.10  and  4.3.1.11  pertain  to  data 
pattern  messages  but  not  single  card  (LMF  SC)  messages. 

4.3.1.10.  Separator.  If  the  message  is  data  pattern  and  not 
single  card  (LMF  SC),  this  paragraph  applies  and  a  space  character 
(no  punch)  separator  must  be  present  following  the  TOF  field.  Use 
of  a  space  separator  in  this  field  on  non-data  pattern  or  single 
card  data  pattern  messages  shall  result  in  the  message  being 
rejected  and  an  "I>A^ALID  HEADER"  service  message  generated  to  the 
input  port/channel. 

4.3.1.10.1.  Check  2. 10. a.  Check  for  space  character. 

Error  Condition  -  Any  character  other  than  a  space 
following  the  TOF  field. 

Error  Resolution  -  An  error  in  the  separator  field 
results  in  message  rejection  for  "INVALID  HEADER". 

4.3.1.11.  Record  Count  Field.  If  the  message  is  data  pattern, 
and  not  single  card,  this  paragraph  applies.  This  field  must  be  a 
four  character  Record  Count  Field.  There  shall  be  no  exceptions. 

The  record  count  is  Intended  as  a  further  safeguard  against  lost 
data.  The  Record  Count  field  may  consist  of  the  letters  MTMS ,  the 
letters  PLTS,  or  a  four  digit  number  in  the  range  0003-0500.  No 
other  characters  shall  be.  permitted  in  a  message  received  from  a 
subscriber  terminal.  If  the  field  is  numeric,  it  must  be  a  count 
of  the  actual  number  of  records  (cards  or  line  blocks)  in  the 
message,  including  the  header  and  trailer.  Since  this  field  does 
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not  apppar  in  a  single  card  (LMF  SC)  message,  and  a  record  count  of 
two  would  indicate  only  a  header  and  trailer,  the  minimum  acceptable 
record  count  is  0003.  The  maximum  record  count  which  may  be 
specified  in  this  field  is  0500.  A  Record  Count  field  of  MTMS 
indicates  either  that  the  message  originator  wishes  to  forego  a 
record  count  check  (MTMS  also  in  trailer)  or  that  the  true  record 
count  will  appear  in  the  trailer  card.  Messages  with  a  Record  Count 
Field  containing  MTMS  in  both  header  and  trailer  or  containing  PLTS 
in  the  header  may  exceed  the  500  line  block  limit,  up  to  a  maximum 
of  556  line  blocks.  The  record  count  field  shall  be  saved  for  later 
comparison  with  the  record  count  field  in  the  trailer  card  to  ensure 
that  the  record  count  is  correct.  This  is  also  described  in  detail 
under  End-of-Message  processing.  Use  of  the  Record  Count  field  on 
non-data  pattern  or  single  card  data  pattern  messages  shall  result 
in  the  message  being  rejected  and  an  "INVALID  HEADER"  service 
message  being  generated  to  the  input  port/channel . 

4.3.1.11.1.  Check  2. 11. a.  If  the  field  is  numeric,  the  value  of 
the  field  shall  be  checked. 

Error  Condition  -  A  Record  Count  Field  value  which  is 
less  than  0003  or  higher  than  0500. 

Error  Resolution  -  Any  error  shall  result  in  rejection 
for  "INVALID  RECORD  COUNT".  There  shall  be  no  exceptions. 

4.3.1.11.2.  Check  2.11.b.  A  Record  Count  field  containing  the 
letters  PLTS  or  MTMS. 

Error  Condition  -  Any  alphabetic  characters  other  than 
PLTS  or  MTMS  in  this  field.  See  para  4.3.7  for  ASC  pilot  exceptions. 

"rr  r  Resolution  -  The  message  shall  be  rejected  and 
in  "T'.".'AMD  R-’:  '  D  “.■;N'T"  service  generated  to  the  input 
port  channel . 

•..3.1.12.  Security  Redundancy  Field  Sentinel.  Following  the 

record  count  field  if  the  message  is  data  pattern  (excluding  single 
card  message),  or  following  the  TOF  field  if  it  is  teletypewriter, 
must  be  the  dash  ar  hyphen  (ITA2  uppercase  "A",  card  "11"  punch) 
a^lin:  l ue  start  of  the  Security  Redundancy  field. 

■♦.3.1.12.1.  Check  2. 12. a.  Check  for  security  sentinel. 

-rror  londition  -  Anv  character  other  than  the  dash. 


Error  Resolution  -  The  message,  shall  be  rejected  and 
a  "ih  -ij.ID  header"  service  message  generated  to  the  input 
p<  ri  lannel.  ''se  of  thl.s  sentinel  on  a  single  card  message  shall 
T'  suit  in  message  rejection  for  "INVALID  HEADER". 


4.3.1.13.  Security  Redundancy  Field,  When  the  message  is  "A" 

SEL  teletypewriter,  the  character  following  the  dash  must  be  a 
downshift  (SI/LTRS).  Since  there  is  no  record  count  field  in  this 
format,  the  upper  case  of  the  TOF  field  is  continued  through  the 
dash,  then  the  lower  case  is  required  for  the  security  field.  There 
is  no  provision  for  this  field  in  a  single  card  message  and  its  use 
shall  result  in  message  rejection  for  "INVALID  HEADER".  In  the 
JANAP  format,  the  four  character  Security  Redundancy  field  shall  be 
validated  in  different  ways.  All  four  characters  of  the  security 
redundancy  fiejd  must  be  identical  to  the  single  security  character 
previously  valiaated  (the  fourth  data  character  of  the  header, 
paragraph4 . 3 . 1 . 3 )provided  the  message  is  not  addressed  to  an  Allied 
destination  or  is  not  an  AUTODIN  Limited  Privacy  Service  (ALPS) 
message.  If  the  message  is  addressed  to  an  Allied  destination,  the 
last  two  character  positions  of  the  Security  Redundancy  field  must 
than  be  valid  transmission  release  codes  (TRCs).  The  TRC  is  a  two 
character  field  which  serves  to  ensure  that  a  message  can  be 
transmitted  to  the.  Routing  Indicators  assigned.  It  is,  essentially, 
a  double  check  on  the  release  of  a  message  to  non-U. S.  subscribers, 
so  that  an  erroneously  inserted  or  garbled  Routing  Indicator  will 
not  cause  release  to  an  Allied  destination  of  a  message  not  intended 
for  such  release.  If  the  characters  in  the  TRC  field  of  a  JANAP 
format  message  being  received  on  an  Allied  channel  are  not  valid  TRC 
characters,  the  message  shall  be  rejected  since  an  Allied  JANAP  user 
must  employ  a  TRC.  Two  characters  ("C"  and  "U"),  may  be  either 
security  or  TRC  characters;  therefore,  the  TRC  field,  although  a 
part  of  the  Security  Redundancy  field,  shall  be  validated 
separately.  If  the  message  is  ALPS,  the  third  character  must  be  a 
"V"  and  the  fourth  character  must  be  a  valid  community-of-interest 
designator.  The  last  two  characters  (whether  TRC,  ALPS,  or 
security)  shall  be  used  later  to  check  against  each  routing 
indicator  and  also  against  the  equivalent  field  in  Format  Line 
Four.  Note  that  FL4  must  be  present  whenever  a  TRC  indication  is 
present  in  FL2 . 

4.3.1.13.1.  Check  2. 13. a.  For  "A"  select  message,  check  for 
downshift  character. 

^rror_Condition  -  Absence  of  the  downshift. 

Error  Resolution  -  The  message  shall  be  rejected, 
without  exception,  and  an  "INt'ALID  HEADER"  service  message  shall  be 
generated  to  the  input  port /channel . 

4.3.1.13.2.  Check  2.13.b.  Check  the  first  two  security  characters 
against  the  single  security  character  field  (see  Check  2. 3. a.) 

Error  Condition  -  The  first  two  characters  are  not 
Identical  to  the  single  character  security  field. 

Error  Resolution  -  The.  message  shall  be  rejected  and 
an  "INVALID  SECURITY  FIELD"  service  message  shall  be  generated  to 
the  input  port/channel . 
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■4.3.1.13.3.  Check  2.13.C.  The  last  two  characters  of  the  Security 
Redundancy  field  shall  be  checked  to  see  if  they  are  valid  TRC 
characters,  ALPS  designator  and  community-of-interest  indicator,  or 
security  characters. 

Error  Condition  -  The  two  characters  fall  the 
validation  check  (not  TRC  characters,  ALPS,  or  security  characters). 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "INAi’ALID  SECCRITA'  FIELD  -  TRC"  service  message  shall  be  generated 
to  the  input  port /channel . 

4.3.1.13.4.  Check  2.13.d.  If  more  than  one  TRC  is  used  in  this 
field,  (two  is  the  maximum  allowed  per  transmission)  they  are 
checked  for  alphabetical  order. 

Error  Condition  -  The  characters  are  not  in 
alphabetical  order. 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "INVALID  SECURIH’  FIELD  -  TRC"  service  message  shall  be  generated 
to  the  input  port /channel . 

4.3.1.14.  Start  of  Routing  (SOR)  Field.  Header  validation  then 
shall  proceed  to  the  SOR  field.  If  the  message  is  "A"  select  this 
is  a  four  character  field,  upshift  (SO/FIGS),  dash,  dash,  downshift 
(Sl/LTRS).  If  other  than  "A"  select,  the  field  is  the  two-character 
field,  dash  dash. 

Error  Condition  -  Any  error  in  this  field. 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  " INVALID  HLADER"  service  message  is  generated  to  the  input 
port  c.';,innel.  There  are  no  exceptions. 

4.3.2.  Header  Valida t ion/Ver if icat ion  of  the  Routing  Indicator 
(RI)  Field. 


4. 3. 2.1.  Routing  Indicator  (RI)  Field.  The  RI  is  the  "address" 
of  a  message.  In  teletypewriter  and  single  card  messages  this  first 
character  must  immediately  follow  the  SOR  field.  In  teletypewriter 
messages  ("A"  or  "H"  SEL)  with  more  than  one  RI ,  each  successive  RI 
must  be  separated  by  either  one  space  or  by  a  valid  End-of-Line 
(EOL)  sequence  consisting  of  two  carriage  return  (CR)  functions  and 
one  line  feed  (LF)  function.  An  RI  may  not  be  split  by  either 
spaces  or  by  an  EOL  sequence  in  any  instance  (teletypewriter,  card, 
or  data  pattern  message).  For  multiple  card  and  data  pattern 
messages,  spaces  (no  card  punch)  are  allowed  between  RIs  and  between 
the  last  RI  in  a  line  block  (card)  and  the  end-of-llne  block. 

4. 3. 2. 1.1.  Check  3.1. a.  The  first  character  must  immediately 
follow  the  SOR  field. 
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Error  Condition  -  First  character  not  found 
immediately  following  the  start-of-rout ing  field. 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INTALID  ROUTIN'G  FIELD"  with  an  automatic  generated  service  to  the 
input  port/channel .  There  shall  be  no  exceptions. 

A. 3. 2. 1.2.  Check  3.1. b.  N'o  RI  may  exceed  seven  characters. 

Error  Condition  -  A  routing  indicator  contains  eight 
or  more  characters. 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INVALID  ROUTING  FIELD"  with  an  automatic  generated  service  to  the 
input  port/channel.  No  deliveries  shall  be  made  and  there  shall  be 
no  exceptions. 

4. 3. 2. 1.3.  Check  3.1.c.  No  presence  of  shift  characters  or 
"lettering  out"  (except  for  the  single  upshift  necessary  before  the 
EOR  in  an  "A"  select  message. 

Error  Condition  -  Shif t-in/shif t-out  function 
separating  routing  indicators. 

Error  Resolution  -  The  message,  shall  be  rejected  for 
"INV.ALID  ROUTING  FIELD"  with  an  automatic  generated  service  to  the 
input  port/channel.  No  deliveries  shall  be  made  and  there  shall  be 
no  exceptions. 

4. 3. 2. 1.4.  Check  3.].d.  Presence  of  non-alpha  be  tic.  o’- 
non-separator  characters  in  this  field. 

Error  Condition  -  Detection  of  a  numeric  character  in 

this  field. 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INVALID  ROUTING  FIELD"  with  an  automatic  generated  service  to  the 
input  port/channel.  No  deliveries  shall  be  made  and  there  shall  be 
no  exceptions. 

4. 3. 2. 1.5..  Check  3.1.e.  Mixture  of  GENSER  and  DSSCS  community 

RIs  on  a  Y  or  R/Y  channel. 

Error  Condition  -  Any  mixed  "R"  and  "Y"  routing 
indicators  in  this  field  on  a  Y  or  R/Y  channel. 

Error  Resolution  -  The  message  shall  be  rejected  for 
"IN’V.ALID  ROUTIN'G  FIELD"  with  an  automatic,  generated  service  to  the 
input  port/channel.  :,’o  deliveries  shall  be  made  and  there  shall  be 
no  exceptions. 

4. 3. 2. 1.5.  Check  3.1.f.  Chec’ic  for  more  than  500  RIs  in  this 
field. 


Error  Condition  -  501  or  more  RIs  in  this  field 


Error  Resolution  -  The  message  shall  be  rejected  for 
"EXCESSIVE  ROUTING  FIELD"  with  an  automatic  generated  service  to  the 
input  port/channel .  No  deliveries  shall  be  made  and  there  shall  be 
no  exceptions. 


•4. 3. 2. 1.7.  Check  3.1.g.  No  more  than  one  Rl  on  a  single  card 
(LMF  sc)  message. 

Error  Condition  -  Two  RIs  on  a  single  card  message. 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INVALID  ROUTING  FIELD"  with  an  automatic  generated  service  to  the 
input  port/channel.  No  deliveries  shall  be  made  and  there  shall  be 
no  exceptions. 


4. 3. 2. 1.8.  Check  3.1.h.  An  RI  may  not  be  split  by  an  end-of-line 
(EOL)  sequence  or  End-Of-Line  Block  (EOLB). 

Error  Condition  -  A  routing  indicator  is  split  by  a 
valid  EOL  (2  CR,  1  LF)  or  EOLB  (end  of  card). 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INVALID  ROUTING  FIELD"  with  an  automatic,  generated  service  to  the 
input  port/channel.  No  deliveries  shall  be  made  and  there  shall  be 
no  exceptions. 


4. 3. 2. 1.9.  Check  3.1.i.  Each  successive  RI  must  be  separated  by 
one  (and  only  one)  space  or  by  a  valid  EOL  (2  CR ,  iLF)  sequence  or 
EOLB. 


Error  Condition  -  Any  character  other  than  a  single 
space  character  or  a  valid  EOL  (2CR,  ILF)  sequence  or  an  EOLB. 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INVALID  ROUTIN'G  FIELD"  with  an  automatic,  generated  service  to  the 
input  port/channel.  No  deliveries  shall  be  made  and  there  shall  be 
no  exceptions. 

4. 3. 2. 2.  End-of-Rout inn  Field.  The  JANAP  format  end-of-rout ing 

(EOR)  consists  of  either  the  t.iree  character  field  upshift 
(SO/FIGS),  period  (.),  downshift  (Sl/LTRS)  for  "A"  select  messages 
or  the  one  character  field  of  period  (.)  for  other  selects.  For  "A" 
and  "n"  select,  the  period  must  be  immediately  followed  by  a  valid 
end-of-line  (EOL)  sequence  (2  CR,  1  LF).  For  card  format  messages 
("D"  select),  the  remainder  of  the  card  following  the  ECR  must  be 
blank.  Any  characters  between  a  card  EOR  and  the  end  of  the  card 
shall  cause  message  rejection.  The  only  exception  is  a  single  card 
message  (L.'!F  SC)  which  shall  be  assumed  to  have  both  its  text  and 
EOM  field  following  the  EOR.  For  magnetic  tape  messages  ("B"  or  "C" 
select)  an  end-of-medium  (EM)  character  may  be  used  im.mediately 
following  the  EOR.  The  LM  character  in  any  other  position  shall 
cause  message  rejection. 
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4. 3. 2. 2.1.  Check  3. 2. a 


Validate  that  there  is  a  valid  EOR 


Error  Condition  -  Field  contains  more  than  three 
characters  for  an  "A"  select,  or  contains  an  invalid  EOR  sentinnel. 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INVALID  HEADER"  with  an  automatic  generated  service  to  the  input 
port/channel.  There  shall  be  no  exceptions. 

4. 3. 2. 2. 2.  Check  3.2.b.  "D"  select  multiple  card  message  must 

not  have  extraneous  characters  between  EOR  and  end  of  the  card. 

Error  Condition  -  Any  punch  falling  between  the  EOR 
and  the  end  of  the  card  (Col  80). 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INVALID  HEADER"  with  an  automatic  generated  service  to  the  input 
port/channel.  There  shall  be  no  exceptions. 

4. 3. 2. 2. 3.  Check  3.2.c.  Insure  EM  character,  if  used  in  a  "B"  or 
"C"  select,  is  immediately  following  the  EOR.  If  not  used,  the 
remainder  of  the  line  block  must  be  spaced  filled. 

Error  Condition  -  EM  character  does  not  immediately 
follow  the  EOR  sentinnel. 

Error  Resolution  -  The  message  shall  be  rejected  for 
"INTALID  HEADER"  with  an  automatic  generated  service  to  the  input 
port/channel.  There  shall  be  no  exceptions. 

4.3.3.  Header  Validation/Verification  of  the  Security  Line. 

4. 3. 3.1.  Security  Line  (FL4).  Follo'ving  the  EOR,  the  next  field  to 
be  validated  on  all  teletypewriter  ("A"  or  SEL)  messages  shall 
be  the  security  line,  format  line  four.  FL4  is  optional  for  data 
pattern  messages  having  LMFs  of  33,  DD,  II,  CC,  or  HC ,  but  must  be 
present  whenever  a  TRC  or  ALPS  indication  is  present  in  FL2 .  Data 
pattern  messages  except  single  card  messages,  may  have  an  optional 
pilot,  identified  by  the  letters  "PLTS"  in  the  record  count  field. 

If  a  pilot  is  present,  it  shall  be  validated  as  the  header  but  the 
FL4  to  be  validated  must  follow  the  original  header.  There  mus'  ■  ' 
be  a  FL4  following  the  pilot  header.  For  all  teletypewriter  an.e 
those  data  patter  ■  'es  using  FL4 ,  the  first  four  characters 

following  the  EOR  (original  •■®-’der  on  piloted  card  messages)  must  be 
the  operating  signal  "ZNR"  or  "ZNY"  followed  ry  s-  .  ■"  en  it 

has  been  determined  that  FL4  has  been  properly  employed  and  the 
first  four  ^"“••aclers  are  valid,  the  security  fields  shall  be 
processed.  The  first  of  t'“  •’  '  five  characters  in  lenath  and  may 

consist  of  five  redundant  security  characters,  t'  r  -  ■nndant 
security  sharacters,  one  ALPS  indicator  ("V”)  and  one  ALPS 
communitv-  •  ••  ’st  character  or  three  redundant  security 

characters  and  two  transmission  release  code  (TRC)  characters.  If 
the  fourth  character  of  the  security  field  is  a  "V"  indicating  ALPS 


protection  is  required,  the  next  character  shall  be  checked  to 
Insure  that  it  is  a  currently  valid  ALPS  community-of-interest 
indicator  and  that  the  terminal  from  which  the  message  is  being 
received  is  authorized  use  of  this  ALPS  character.  (When  a  valid 
ALPS  code  is  found,  special  processing  shall  be  entered  so  that  no 
message  data  will  be  written  to  the  history  record  past  the  point  in 
FL4  where  the  ALP?  ode  is  detected.)  Following  the  TRC  field, 
separated  by  a  si  ("/"),  may  be  from  one  to  four  optional  special 
handling  designatoi  (SHD)  fields  (separated  by  a  slash),  each  of 
which  consists  of  a  five-character  repetition  of  a  SHD  character. 

4. 3. 3. 1.1.  Check  4  .l.a.  The  first  four  characters  of  FL4  shall  be 
checked  to  see  if  they  are  "ZNR"  or  "ZNY”  and  a  space. 

Error  Conditions  -  The  first  four  characters  are  not 
"ZNR"  or  "ZNY"  and  a  space;  "ZNY”  and  a  space  is  used,  but  the 
security  redundancy  field  in  FL2  is  "ULTUU";  or  "ZNR"  and  a  space  is 
used  but  the  security  redundance  field  in  FL2  is  other  than  "UUUU". 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "IN’VALID  SECURITY  FIELD"  service  message  automatically  generated 
to  the  input  port/channel. 

4. 3. 3. 1.2.  Check  4 .2. a.  The  first  three  characters  of  the  security 
field  shall  be  validated  to  be  redundant  and  must  match  the  security 
redundancy  field  in  FL2. 

Error  Condition  -  The  characters  are  not  redundant  or 
do  not  match  those  in  FL2. 

Error  Resoluti^  -  The  message  shall  be  rejected  and 
an  "INVALID  SECURITY  FIELD  -  SEC"  service  message  automatically 
generated  to  the  input  port/channel. 

4. 3. 3. 1.3.  Chec'^  4 . 3_^a.  The  next  two  characters  shall  be  checked 
for  security  redundancy. 

Err^r  Condition  -  If  the  FL2  security  redundancy  field 
does  not  indicate  ALPS  processing  or  TRCs  required,  any  characters 
in  these  two  positions  other  than  security  redundancy  characters  are 
in  error. 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "I.T/ALID  SECURITY’  FIELD  -  TRC"  service  message  automatically 
generated  to  the  input  port/channel. 

4.3.3. 1.4.  Check  4.3jb.  The  two  characters  shall  be  checked  for 
valid,  required  TRC  character(s) . 

Error  Condition  -  The  TRC  characters  are  invalid,  not 
redundant  if  only  one  TRC  is  required,  or  not  in  alphabetical  order 
if  more  than  one  TRC  is  required. 


Error  Resolution  -  The  message  shall  be  rejected  and 
an  "INVALID  SECURITY  FIELD  -  TRC"  service  message  automatically 
generated  to  the  input  port/channel. 

4. 3. 3. 1.5.  Check  4.3. c.  If  the  fourth  character  of  the  security 
field  is  a  "V",  ALPS  processing  is  indicated.  The  next  character 
shall  be  validated  to  insure  that  it  is  a  currently  valid  ALPS 
community-of-interest  indicator  and  that  the  terminal  from  which  the 
message  is  being  received  is  authorized  use  of  this  ALPS  character. 

Error  Condition  -  Input  station  not  authorized  use  of 
ALPS  character  or  invalid  community-of-interest  indicator. 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "INVALID  SECURITY  FIELD  -  TRC"  service  message  automatically 
generated  to  the  input  port/channel. 

4. 3. 3. 1.6.  Check  4. 4. a.  After  validation  of  the  security 
redundancy/TRC/ALPS  field,  check  shall  be  made  for  the  Special 
Handling  Designator  (SHD)  sentinel,  a  slash  (/)  or  an  end-of-line 
sentinel  (CRCRLF). 

Error  Condition  -  Any  character  other  than  a  slash  (/) 
preceded  and  followed  by  the  proper  shift  characters  or  a  valid 
end-of-llne  sequence  (CRCRLF)  following  the  previous  field. 


Error  Resolution  -  The  message  shall  be  rejected  and 
an  "INVALID  SECURITY  FIELD  -  SRC"  service  message  is  automatically 
generated  to  the  input  port/channel. 

4.3.3.1«^«  Check  A.A.b.  If  an  SHD  sentinel  is  found,  the  next 
five  characters  must  be  identical  and  must  be  a  valid  SHD  category 
character  as  specified  in  ACP  117. 

Error  Condition  -  The  five  characters  are  not 
redundant,  not  valid  SHD  category  characters,  the  classification  of 
the  message  is  UNCLAS  or  EFTO,  or  the  input  station  is  not 
authorized  the  SHD. 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "INVALID  SECURITY  FIELD  -  SRC"  service  message  automatically 
generated  to  the  input  port/channel. 

A. 3. 3. 1.8.  Check  A.A.c.  If  another  SHD  sentinel  (/)  is  found,  the 
next  SHD  field  shall  be  validated  in  the  same  manner  as  the  first. 
This  shall  be  repeated  for  up  to  four  SHD  fields.  If,  after  either 
the  TRC  field  or  after  any  SHD  field  except  the  fourth,  a  SHD 
sentinel  is  not  found,  there  still  exists  the  possibility  that  the 
message  contains  one,  or  another,  SHD  but  that  the  sentinel  is 
garbled  or  mispositioned.  To  reduce  the  possibility  that  a  SHD 
message  will  be  accepted  without  proper  validation,  the  character 
immediately  following  the  TRC  of  a  valid  SHD  shall  be  validated  to 
be  a  space  or  a  carriage  return. 

Error  Condition  -  A  character  other  than  a  space  or 
carriage  return  is  encountered  following  the  TRC  or  a  valid  SHD. 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "INVALID  SECURITY  FIELD  -  SRC"  automatically  generated  to  the 
input  port ''channel . 

4. 3. 3. 1.9.  Check  A.A.d.  If  a  space  is  encountered  following  the 
TR.C  or  a  valid  SHD  field,  that  character  and  14  characters 
following  it  shall  be  examined  in  an  attempt  to  find  four  redundant 
contiguous  characters  which  would  be  considered  a  suspected  SHD. 

Error  Condition  -  Any  four  contiguous  characters 
(9999,  SSSS,  etc.)  following  the  TRC  or  a  valid  SHD  field.- 

Error  Resolution  -  Message  shall  be  rejected  and  an 
"ILT’ALID  SECURITY  FIELD  -  SRC"  service  message  automatically 
generated  to  the  input  port/channel. 

4.3.3.1.10.  Check  A.A.e.  If  a  carriage  return  is  encountered 
immediately  following  the  TRC  or  a  valid  SHD  field,  it  must  be 
followed  immediately  by  a  second  CR  and  one  line-feed  (CRCRLF). 
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.  Error  Condition  -  A  carriage  return  (CR)  is 

encountered  not  immediately  followed  by  a  second  and  a  line-feed. 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "INh/ALlD  SECURITY  FIELD  -  SRC"  service  message  automatically 
generated  to  the  input  por t/channel. 

4. 3. A.  Routing  Indicator  Validation. 

4. 3. 4.1.  General.  If  a  message  contains  only  one  RI ,  and  that  RI 
is  invalid,  the  message  shall  be  rejected.  If  a  message  is  input 
on  a  Y  or  an  R/Y  channel  and  contains  a  mixture  of  R  and  Y  RIs,  the 
message  shall  be  rejected  regardless  of  RI  validity.  If  a  similar 
message  is  input  on  an  R  channel,  only  the  invalid  RIs  and  those 
beginning  with  a  character  other  than  "R"  shall  be  considered 
invalid  and  shall  be  rejected  individually;  the  message  shall  be 
protected  to  those  valid  GEN'SER  RIs. 

4. 3. 4. 2.  Check.  5.1. a.  RI  validation  shall  determine  whether  the 
RI  is  in  the  I-S/A  AMPE  RI  tables.  Each  1-S/A  AMPE’s  RI  tables 
shall  contain  all  directly  connected  tributaries'  RIs,  all  other 
I-S/A  A-MPEs’  RIs,  and  all  Mon  Automatic  Relay  Centers'  (MARCs) 

RIs.  A  GEMSER  RI  may  be  from  4  to  7  characters  but  must  contain  7 
characters  if  addressed  to  an  I-S/A  AMPE  subscriber.  If  the  RI  is 
a  local  I-S/A  .A-'iPE  subscriber,  the  first  six  characters  shall  be 
checked  for  validity  and  determination  of  delivery  destination,  the 
seventh  ignored.  If  the  RI  is  a  distant  I-S/A  A,'!?E  subscriber  or  a 
MARC,  local  or  remote,  only  the  first  four  characters  shall  be 
checked  for  validity  and  determination  of  delivery  destination.  If 
the  first  four  characters  indicate  a  collective  RI  (RHCR),  the  last 
three  characters  determine  the  actual  collective  list  for  delivery 
destinations. 

Error  Condition  -  A  routing  indicator  is  not  found  in 

t’ne  R.I  tables. 

Error  Resolution  -  If  the  message  contains  only  one 
Pv.1  or  no  valid  RIs,  it  shall  be  rejected  and  an  "IMA’ALID  ROUTIM'G 
REPROTECT  TO"  service  message  automatically  generated  to  the 
originating  subscriber.  If  the  message  contains  at  least  one  valid 
RI ,  it  s'aall  be  accepted  and  processed  for  delivery  to  the  valid 
RI.  An  "IMVALID  ROUTIMG  REPROTECT  TO"  service  message  shall  be 
automatically  generated  to  the  originating  subscriber  advising  of 
the  invalid  RI'^s)  requiring  reprotection. 


4. 3. 4. 2.1.  Check  5.'-.b.  Vnen  the  RI  has  been  determined  to  be 
valid,  the  message  security  shall  be  checked  against  the  security 
of  the  destination  RI .  The  Jest inat ion  RI  security  must  be  equal 
to  O’"  greater  than  the  security  of  the  message. 

Error  Con.!  it  ion  -  Security  of  the  message  is  greater 
tl.an  the  security  assigned  to  the  destination  RI . 


Error  Resolution  -  If  the  message  contained  only  one 
RI ,  or  if  all  Ris  tailed  the  security  check,  the  message  shall  be 
rejected  and  an  "INh,'ALID  ROUTING  -  SEC"  service  message 
automatically  generated  to  the  originating  subscriber.  If  the 
message  contained  at  least  one  RI  which  passed  the  security  check, 
the  message  shall  not  be  rejected  but  shall  be  processed  for 
delivery  to  the  RI  passing  the  check.  The  service  message  shall  be 
automatically  generated  to  the  originating  station  advising  of  the 
remaining  RIs  requiring  reprotection. 

4. 3. 4. 2. 2.  Check  5.I.C.  The  delivery  of  an  EFTO  message  to  an 

Allied  RI  shall  be  prohibited  regardless  of  the  security  level 
assigned  to  the  RI. 

Error  Condition  -  An  EFTO  message  addressed  to  an 

Allied  RI. 


Error  Resolution  -  If  the  message  addresses  only  one 
RI,  or  if  all  Ris  are  Allied,  the  message  shall  be  rejected  and  an 
"INVALID  ROUTING  -  SEC"  service  message  automatically  generated  to 
the  originating  subscriber.  If  the  message  contained  at  least  one 
non-Allied  RI  which  passed  the  security  check,  the  message  shall 
not  be  rejected  but  shall  be  processed  for  delivery  to  the  RI 
passing  the  check.  The  service  message  shall  be  automaticallly 
generated  to  the  originating  subscriber  advising  the  remaining  Ris 
requiring  reprotection. 

4. 3. 4. 2. 3.  Check  5.3.d.  Each  RI  shall  be  checked  to  determine 

if  it  requires  a  validating  TRC.  All  messages  addressed  to 
non-U. S.  RIs  require  a  TRC.  Messages  addressed  to  U.S.  Ris  are  not 
checked  against  the  TRC  unless  the  message  is  from  an  Allied  J.ANAP 
user . 


Error  Condition  -  Use  of  an  invalid  or  incorrect  TRC, 
or  absence  of  a  TRC  when  required. 

Error  Resolution  -  If  the  message  is  addressed  to 
only  one  Rl  or  if  all  Ris  fail  the  TRC  check,  the  message  shall  be 
rejected  and  an  "INVALID  ROUTING  REPROTECT  -  TRC"  service  message 
automatically  generated  to  the  originating  subscriber.  If  the 
message  contained  at  least  one  valid  RI  which  passed  the  TRC  check, 
the  message  shall  not  be  rejected  but  shall  be  processed  for 
delivery  to  the  RI  passing  the  check.  The  service  message  shall  be 
automatically  generated  to  the  originating  subscriber  advising  of 
the  remaining  Ris  requiring  reprotection.  If  the  message  is  a 
magnetic  tape  medium  (L.MF  of  BB,  DD,  or  II)  with  an  Allied  RI ,  the 
service  message  shall  be  "INVALID  ROUTING  REPROTECT  -  L.MF"  instead 
of  "TRC"  since  this  media  cannot  be  delivered  to  Allied  users. 

(They  do  not  have  compatible  equipment.) 
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-4. 3. 4, 2. 4.  Check  5.3.e.  If  the  message  is  ALPS  (U.S.  RIs  only), 
the  destination  associated  with  each  RI  shall  be  tested  for  ALPS 
communi ty-of-interest  authorization. 

Error  Condition  -  Invalid  or  absence  of  the 
communi ty-of-interest  designator . 

Error  Resolution  -  If  the  message  is  addressed  to 
only  one  RI  or  if  all  RIs  fail  the  ALPS  check,  the  message  shall  be 
rejected  and  an  "INVALID  ROUTING  REPROTECT  -  TRC"  service  message 
automatically  generated  to  the  originating  subscriber.  If  the 
message  contained  at  least  one  valid  RI  which  passed  the  ALPS 
check,  the  message  shall  not  be  rejected  but  shall  be  processed  for 
delivery  to  the  RI  passing  the  check.  The  service  message  shall  be 
automatically  generated  to  the  originating  subscriber  advising  of 
the  remaining  RIs  requiring  reprotection. 

4. 3. 4. 2. 5.  Check  5.3.f.  If  one  or  more  special  handling 
designator  (SHD)  codes  are  present,  the  destination  RI  shall  be 
checked  for  authorization  to  receive  each  SHD. 

Error  Condition  -  Destination  RI  not  authorized  to 
received  a  particular  SHD. 

Error  Resolution  -  If  the  message  is  addressed  to 
only  one  RI  or  if  all  RIs  fail  the  SHD  check,  the  message  shall  be 
rejected  and  an  "INVALID  ROUTIIJG  REPROTECT  -  SRC"  service  message 
automatcally  generated  to  the  originating  subscriber.  If  the 
message  contained  at  least  one  valid  RI  which  passed  the  SHD  check, 
the  message  shall  not  be  rejected  but  shall  be  processed  for 
delivery  to  the  RI  passing  the  check.  The  service  message  shall  be 
automatically  generated  to  the  originating  subscriber  advising  of 
the  remaining  RIs  requiring  reprotection. 

4. 3. 4. 2. 6.  Check  5.3.g.  Each  RI  shall  be  checked  against  the 
L.MF  of  the  message.  Three  LNFs  indicate  magnetic  tape  traffic  (33. 
DD,  and  II)  and  these  messages  shall  not  be  delivered  to  a 
non-compatible  destination  RI.  In  addition,  three  LMFs  (HC-Cards, 
EA-eight  level  paper  tape,  and  RT-five  level  paper  tape)  indicate 
the  originator's  desire  that  medium  exchange  be  prohibited,  and 
these  also  shall  not  be  delivered  to  a  non-compatible  terminal. 
Single  card  (SC)  messages  shall  not  be  delivered  to  a 
teletypewriter  terminal. 

Error  Condition  -  Any  incompatibility  detected  as  a 
result  of  the  above  check  (e.g.  addressing  a  SC  message  to  a  .''.ode 
II  or  Mode  V). 


Error  Resolution  -  If  the  message  is  addressed  to 
only  one  RI  or  if  all  RIs  fall  the  LMF  check,  the  message  shall  be 
rejected  and  an  "I.'iVALID  ROUTI.NG  REPROTECT  -  LMF"  service  message 
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automatically  generated  to  the  originating  subscriber.  If  the 
message  contained  at  least  one  valid  RI  which  passed  the  LMF  check, 
the  message  shall  not  be  rejected  but  shall  be  processed  for 
delivery  to  the  RI  passing  the  check.  The  service  message  shall  be 
automatically  generated  to  the  originating  subscriber  advising  of 
the  remaining  RIs  requiring  reprotection. 

•4. 3. 4. 2. 7.  Check  5.3.h.  Some  multi-card  and  magnetic  tape 
messges  may  not  have  a  FL4  and  delivery  of  these  messages  shall  not 
be  made  to  teletypewriter-only  (narrative)  terminals  since  both 
JANAP  and  AGP  formats  require  FL4  on  all  teletype  traffic.  In 
addition,  card  and  magnetic  tape  messages  having  a  pilot  shall  not 
be  delivered  to  an  AGP  terminal  since  format  exchange  would  cause 
output  of  an  AGP  header  with  no  FL4. 

Error  Condition  -  Any  violation  of  the  above  check 
(e.g.  card  to  card  message  with  no  FL4  addressed  to  a  terminal  who 
uses  AGP  format). 

Error  Resolution  -  If  the  message  is  addressed  to 
only  one  RI  or  if  all  RIs  fail  this  check,  the  message  shall  be 
rejected  and  an  "IN'VALID  ROUTING  REPROTECT  -  MFE"  service  message 
automatically  generated  to  the  originating  subscriber.  If  the 
message  contained  at  least  one  valid  RI  which  passed  this  check, 
the  message  shall  not  be  rejected  but  shall  be  processed  for 
delivery  to  the  RI  passing  the  check.  The  service  message  shall  be 
automatically  generated  to  the  originating  subscriber  advising  of 
the  remaining  RIs  requiring  reprotection. 

4. 3. 4. 2. 8.  Check  5.3. i.  If  the  message  contains  a  collective 
RI,  the  Initial  check  shall  be  to  determine  if  the  CRI  is  valid. 

Error  Condition  -  Use  of  an  invalid  CRI. 

Error  Resolution  -  If  the  CRI  is  invalid  and  the 
message  was  only  addressed  to  that  RI  or  did  not  contain  any  valid 
RIs,  the  message  shall  be  rejected  and  an  "INVALID  ROUTING 
REPROTECT  TO"  service  message  shall  be  automatically  generated  to 
the  originating  subscriber.  If  the  message  contained  at  least  one 
valid  RI  which  passed  this  check,  the  message  shall  not  be  rejected 
but  shall  be  processed  for  delivery  to  the  RI  passing  the  check. 

The  service  message  shall  be  generated  to  the  originating 
subscriber  advising  of  the  RIs  requiring  reprotection.  Detection 
of  a  CRI  in  an  ALPS  message  shall  result  in  message  rejection  and 
the  automatic  generation  of  an  "INVALID  SECURITY  FIELD  -  TRC" 
service  message. 

4. 3. 4. 2. 9.  Check  5.3.j.  A  check  shall  be  made  to  determine  if 
the  input  subscriber  is  authorized  to  introduce  a  CRI  or  a  CAD. 

One  exception  to  this  check  shall  be  that  ports 'channels  authorized 
to  input  EC?  messages  may  input  CRIs  in  their  EC?  messages,  but  not 
in  messages  of  other  precedences  unless  they  are  also  classmarked 
for  this  capability. 
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Error  Condition  -  Attempted  input  of  a  CRI/CAD  by  a 
port/channel  not  classmarked  for  CRi/CAD  input  and  not  an  ECP  CRI 
by  an  authorized  ECP  port/channel. 

Error  Resolution  -  The  message  shall  be  rejected  and 
an  "UNAUTHORIZED  USE  OF  CRi/CAD"  service  message  shall  be 
automatically  generated  to  the  input  port/channel. 

4.3.5.  End-of  Message  (EOM)  processing.  Upon  completion  of  SOMS 
validation,  a  continual  scan  of  each  message  for  the  end  of  message 
sequence  (EOMS)  shall  be  performed.  The  J.VN'AP  narrative  format  EOM 
procedurally  consists  of  two  carriage  returns,  eight  line  feeds, 
and  the  letters  "NNNN"  but  the  minimum  required  for  recognition  by 
the  1-S/A  AMPE  shall  be  one  line  feed  and  four  N's.  In  a-multiple 
block  data  pattern  message  it  shall  consist  of  the  letters  "NNNN" 
in  columns  77  through  80  of  the  last  line  block/card.  This  scan 
and  others  that  shall  be  performed  for  the  detection  of  specific 
character  sequences  are  described  in  this  section. 

4. 3. 5.1.  Straggler  Protection.  A  "straggler"  is  caused  by  a 
message  without  a  valid  start  of  message  sequence  (SOMS)  following 
a  message  without  a  valid  end  of  message  sequence  (EOMS)  on  an 
asynchronous  channel,  or  two  messages  entered  as  one  on  a 
synchronous  channel  and  framed  SOH-ETX  as  a  single  message.  To 
protect  against  straggler  messages,  the  I-S/A  A.MPE  shall  validate 
the  Originating  Station  Serial  Number  (OSSN)  in  the  message  header 
against  the  Trailer  Station  Serial  Number  (TSSN)  found  in  the 
message  trailer.  Failure  of  straggler  validation  shall  result  in 
message  rejection  unless  the  message  is  Flash  precedence,  and  the 
automatic  generation  of  a  "SUSPECTED  STRAGGLER”  service  message  to 
the  input  port  or  channel.  Flash  messages  shall  be  accepted  and 
the  service  message  generated  shall  advise  the  input  port  or 
channel  "HIGH  PRECEDENCE  MESSAGE  ACCEPTED,  REPROTECT  SUSPECTED 
STRAGGLER”. 

4. 3. 5. 1.1.  Data  Pattern  Messages.  The  EOMS  must  be  the  "NN’M<" 
sequence  in  columns  77  through  80.  The  EOM  line  block  must  contain 
the  ETX  character  in  the  third  framing  character  (FC3)  and  it  is 
incumbent  on  the  terminal  to  ensure  that  the  EOM  is  properly 
recognized  and  the  block  properly  framed.  Receipt  of  an  ETX 
framing  character  without  a  correct  EOM  shall  result  in  message 
rejection  and  generation  of  an  "INE/ALID  EOM"  service  message  to  the 
input  port/channel.  Receipt  of  a  valid  EOM  without  the  ETX  shall 
result  in  non-recognition  of  the  EOMS  and  an  input  message  hiatus 
rejection  of  a  following  SOH  lineblock,  and  the  ultimate  rejection 
of  the  errored  message.  Related  to  EO'!  processing  shall  be  the 
check  for  a  valid  record  count  field  in  a  multiple  line  block  card 
or  magnetic  tape  message.  There  is  i  relationship  between  this 
field  and  the  record  count  field  of  the  header.  The  trailer  record 
count  field  must  be  either  "MT’iS" ,  signifying  a  message  from  a 
magnetic  tape  terminal  which  does  not  count  line  blocks,  or  a  four 
digit  numeric  field.  The  use  of  "PLTS"  in  the  trailer  shall  be 
prohibited  and  shall  result  in  message  rejection  and  an  "IN'v’ALID 


RECORD  COUNT"  service  message  being  automatically  generated  to  the 
input  port /channel.  If  "MTMS"  appears  in  the  record  count  field  of 
both  the  header  and  trailer,  no  further  checking  of  the  actual  line 
block/card  count  shall  be  performed.  If  a  number  appeared  in  the 
header  and  "MTMS"  or  a  number  in  the  trailer,  the  actual  line 
block/card  count  received  shall  be  checked  against  the  header 
number,  and  the  trailer  record  count  field  shall  effectively  be 
ignored.  If  "MTMS"  appears  in  the  header  record  count  field  and 
the  trailer  field  contains  a  number,  that  number  shall  be  compared 
to  the  actual  count  of  the  line  blocks/cards  received.  Any 
disparity  in  the  above  two  instances  shall  result  in  the  message 
being  rejected  and  an  "1N\'AL1D  RECORD  COUNT"  service  message  being 
automatically  generated  to  the  input  port/channel.  When  the 
message  header  record  count  field  contains  the  pilot  indicator 
"PETS",  there  shall  be  no  check  of  either  the  header  or  trailer 
record  counts  against  the  actual  number  of  blocks  received. 

4. 3. 5. 1.2.  TeletypewTiter  (Narrative)  Messages.  The  minimum  EOMS 
recognizable  shall  be  one  linefeed  character  and  four  N's  in  an 
uninterrupted  sequence.  More  than  eight  line  feeds,  extraneous 
characters  in  the  linefeed  field,  or  extraneous  characters  between 
the  TSSN  and  the  required  EOMS  are  acceptable  provided  that  the 
straggler  sentinel  (■/)  falls  within  23  characters  of  the  required 
line  feed  and  the  required  EOMS  is  not  interrupted.  If  the  EOMS 
does  not  fall  within  23  characters  of  the  TSSN,  the  message  shall 
be  rejected  and  a  "SUSPECTED  STRAGGLER"  service  message 
automatically  generated  to  the  input  port/channel.  On  asynchronous 
channels,  an  invalid  EOMS  shall  result  in  either  an  input  message 
hiatus  or  a  two  consecutive  SOM  condition.  Either  shall  result  in 
message  rejection.  On  synchronous  channels,  detection  of  the  ETX 
framing  character  without  prior  detection  of  a  valid  EOMS  shall 
result  in  message  rejection  and  an  "INVALID  EOM"  service  message 
automatically  generated  to  the  input  port/channel. 

1.3.5.2.  Cancel  Transmission  Sequence  (CAiNTRANS).  The  I-S^k  .-''PE 
.Iso  shall  scan  for  the  presence  of  a  CANTRANS  which  procedunlly 
consists  of  3  E's,  each  separated  by  a  space,  the  letters  "AR" ,  and 
an  EOMS  of  two  carriage  returns,  eight  line  feeds,  and  four  N’'s. 

The  minimum  recognizable  by  the  I-S/A  AMPE  shall  be  two  E's 
separated  and  followed  by  a  space,  "AR" ,  one  linefeed,  and  four 
'."s.  When  a  CANTR.A.NS  is  recognized,  the  message  shall  be  discarded 
by  the  I-S/A  AMPE  with  a  notification  to  the  system  I-S'A  T'.?'' 
operator  that  the  message  has  been  discarded. 

4.3.5.3.  Excessive  Message  Length.  An  additional  check  that  shall 
be  performed  during  receipt  of  message  text  is  a  count  of  total 
line  bloc’ics /characters  being  received.  Should  this  count  exceed 
536  line  blocks  (44,430  characters),  the  message  shall  be  rejected 
and  an  "EXCESSIVE  MESSAGE  LENGTH"  service  message  automatically 
generated  to  the  input  port/channel.  Mode  II  channels  shall  be 
limited  to  125  line  bloc'xs  (10,000  characters). 
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4. 3. 5. 4.  Excessive  Input  Hiatus.  Incoming  messages  shall  be  also 
monitored  for  any  delay  (hiatus)  in  receipt  by  the  I-S/A  AMPE. 

Wher  no  additional  data  is  received  for  a  non-CRITIC  message  in 
progress  for  a  period  of  approximately  three  minutes,  the  message 
shall  be  rejected  and  a  "NO  EOM  RECEIVED”  service  message 
automatically  generated  to  the  input  port  or  channel. 

4. 3. 5. 5.  Framing  Character  (FC)  Processing.  Framing  characters 
shall  be  validated  for  all  input  messages.  On  asynchronous 
channels,  these  shall  have  been  inserted  and  the  message  blocked 
and  framed  by  the  I-S/A  AMPE  itself  so  that  FC  validation  shall  be 
essentially  a  self-checking  process  by  the  I-S/A  AMPE.  On 
synchronous  channels,  FC  validation  shall  ensure  proper  framing  by 
the  terminal  device.  Any  framing  character  error  shall  result  in 
message  rejection  with  a  "REPROTECT  TO  ALL  ADDEES"  service  message 
being  automatically  generated  to  the  input  port /channel .  In 
addition,  notification  of  the  FC  error  shall  be  provided  to  the 
system  1-S/A  AMPE  operator  so  that  any  FC  errors  caused  within  the 
I-S/A  AMPE  itself  may  be  detected  and  corrective  action  taken. 

4.3.6  RI  Processing  Exception:  Messages  may  be  transmitted  to  a 
given  I-S,'A  AMPE  from  a  connected  ASC  (as  the  result  of  an  ASC 
altroute  action)  that  contain  ASC  pertinent  destination  RIs  which 
are  not  normally  pertinent  to  the  given  I-S/A  AMPE.  This  is 
because,  unlike  the  I-S/A  AMPE,  an  ASC  delivers  an  altrouted 
message  with  the  destination  RI  intact  (as  received  from  the 
message  originator)  to  the  alternate  delivery  station.  Each  ASC 
altroute  invoke  or  revoke  action  involving  an  I-S/A  A.MPE  as  an 
alternate  delivery  station  will  result  in  ASC  transmission  of 
alternate  routing  notification  service  messages  (specified  in  the 
AUTODIM  System  Functional  Specification,  Appendix  B,  Section  II)  to 
the  affected  I-S/A  A.MPE  preceding  any  altrouted  messages  (invoke) 
and  upon  termination  or  modification  of  the  altroute  action 
(revoke).  The  I-S/A  A.MPE  shall  accept  these  altrouted  messages 
from,  directly  connected  ASCs  for  delivery  to  pre-det ermined 
alternate  delivery  subscribers.  If  a  pre-determined  alternate 
delivery  subscriber  is  a  distant  I-S/A  .\MPE  subscriber  (because  the 
distant  I-S/A  AMPE  is  not  directly  connected  to  an  ASC)  the  I-S/A 
AMPE  receiving  the  message  from  its  connected  ASC  shall  append  an 
alternate  routing  pilot  containing  the  RI  of  the  distant  alternate 
delivery  subscriber  and  forward  the  message  to  the  distant  I-SAA 
AMPE.  In  no  case  shall  the  I-S/A  ,V‘‘FE  return  a  message  received 
from  a  connected  ASC  to  the  same  ASC  or  another  connected  ASC  based 
solely  on  the  received  destination  RI. 

4.3.7  .Ab'TODIM  System  Cenerated  Pilots.  The  I-S/A  .AMPE  shall 
accept  and  process  for  delivery  messages  received  from  connected 
.AuTODIM  Switching  Centers  (.ASCs)  containing  "pilots"  as  described 
in  the  .AUTODIN'  System  Functional  Specification,  Para  412.  Vote 
that  a  message  containing  an  AUTODIN’  system  generated  pilot  will 
not  be  accepted  by  an  ASC. 
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aerier3t.cr  the  associa-^.  raessage  haj=  ht'^ri  nt -cricwledaca  L" 

Cite  I _ Consequent ly  ,  t*ie  LDMI\  also  does  not  upaate  cne  last 

accepted  CSN  on  a  Mode  V  channel  until  the  message  has  been 
validated  and  accepted. 


4.4  J.\NAP  Message  Format.  -  For  NAVY  LDMX 
validation/verif ication  purposes,  the  JA!JAP  format  is  divided 
into  fourteen  parts:  Header  data  up  to  and  including  the 
Start-of -Routing  Sequence  (Format  Line  2);  the  Routing 
Indicator  Field  (still  a  part  of  Format  Line  2);  "DE"  Line 
(Format  Line  3);  the  Security  Line  (Format  Line  4);  Passing 
Instructions  (Format  Line  4  Extensions);  Operating  Signals; 
the  Date  Time  Group  (Format  Line  5) ;  the  Message  Originator 
(Format  Line  6);  the  Action/Information  Addressees  (Format 
Line7/8);  the  Exempt  Addressee  (Format  Line  9);  the  Accounting 
Symbol  (Format  Line  10);  the  End  of  Header  (Format  Line  11); 
the  Message  Classification  (Format  Line  12);  and  the  End  of 
Message  (Format  Lines  13  through  16)  . 


4  . .1  Format  Line  2  Processing  Through  the  Start-of -Routine; . 


4.  .1.1  Precedence  Field.  -  The  first  header  field  to  be 
validated  is  the  precede.nce  field.  The  precedence  field  is 
processed  first.  Once  validated,  the  precedence  is  saved  for 
later  correlation  with  FL5  precedence ( s ) . 


4.  .1.1.1  Check  2.1. a.  -  Precedence  is  a  single  character, 
the  first  character  of  the  header  and  is  validated  to  be  one  of 
five  characters: 


Emergency  Ccm.m.ar.d  Preceience  ''ECP)  which  may 
be  input  cm. ly  on  authcricei  channels. 

Flash 
"O”  -  Immediate 
"P"  -  Priority 
"R"  -  Routine 

Error  Condition  -  If  the  field  is  not  one  of  the  five 
precedence  characters  specified  above. 

Error  Resolution  -  An  error  in  the  precedence  field  of 
either  an  invalid  or  an  unauthorized  character  results  in  the 
message  being  rejected  to  a  service  position  with  the  error 
annotation  "Iir\7ALID  PRECEDENCE".  See  Message  Error  Processing 
for  the  appropriate  response. 


4.  .1..  Lrinauaa^^  Media  7"crr~.a-  '  I.-' _ .  -  T:ie  nc:-:z  fi^ld  t_  r^e 

V a  1  i d.a u a  JAi^Ar  loiiaat,  mai^octuc:  Lian^aLiC^ti  ar*a  Media 
Format  (LMF)  field.  This  is  a  two  character  field  in  which  the 
first  character  (LMFl)  indicates  the  medium  in  which  the  input 
message  was  originally  prepared.  It  is  sometimes  also  called 
the  Input  LMF.  The  second  character  ( LMF2 )  indicates  the  medium 
in  which  the”  originator  prefers  the  message  to  be  delivered  to 
the  addressee.  It  is  sometimes  also  referred  to  as  the  Output 
LMF.  Input  header  processing  merely  validates  the  Input 
Media/LMF  combination.  Further  use  of  the  LMF  in  input 
processing  and  in  output  message  delivery  will  be  discussed 
later . 


4.  ,.1.2.1  Check  2. 2. a.  -  LMF  validation  is  always  combined 

with  the  validation  of  the  Input  Media.  If  the  message  is  from 
a  TI  user,  the  SEL  is  obtained  from  the  second  framing  character 
of  the  TI  line  block.  Otherwise,  it  is  the  second  framing 
character  of  the  header  line  block.  Once  the  SEX-LMF 
combination  passes  validation,  the  LMF  pair  information  is  saved 
for  RI  processing,  which  must  determine  whether  a  message  of  the 
specified  LMF  can  be  delivered  to  a  given  RI. 

Error  Condition  -  If  the  Input  Media/LMF  combination 
does  not  match  an  LDMX  table  entry,  the  Input  Media  is  validated 
separately . 

Error  Resolution  -  If  the  Input  Media  is  invalid,  an 
error  condition  is  loaaed  and  the  messaae  is  rejected 
with  no  exceptions.  A  "REPROTECT  TO  ALL  ADDRESSEES"  service 
message  is  generated. 

When  the  Input  Media  is  valid,  but  one  of  the  LMF 
characters  is  invalid,  it  is  rejected  to  a  service  position  with 
an  "IMVALID  L.MF"  error  annotation.  See  Message  Error  Processing 
for  the  appropriate  response. 

4. 4. 1.3  Single  Security  Character  Field.  -  The  next  field  to 

be  validated  is  the  single  character  security  field.  Once 
validated,  the  security  character  is  saved  for  further  security 
checks  in  format  line  2,  4,  and  12  processing.  The  single 

character  which  indicates  the  security,  must  be  one  of  the 
following  characters: 

"T"  -  Top  Secret 
"S"  -  Secret 
"C"  -  Confidential 
"R"  -  Restricted 

"E"  -  Unclas  E  F  T  0  (encrypted  for  transmission 
only ) 

"U"  -  Unclassified 


• 
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Error  Condition  -  Dett-  ion  of  an  invalid 
security  character. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position,  with  the  error  annotation  "INVALID  SECURITY". 
See  Message  Error  Processing  for  the  appropriate  response. 


4  .  ■■  .  1 . 4  Content  Indicator  Code  (CIO  Field.  -  The  four 
character  CIC  field  contains  information  related  to  the  type  of 
message  being  processed.  The  CIC  is  also  referred  to  as  the 
Communication  Action  Identifier  (CAI).  Certain  CICs  such  as 
ZOVW,  ZZGW,  IJJY,  JGGC,  NGGC ,  etc.  predetermine  further  format 
line  validation  and  internal  processing,  thus  requiring  the 
information  be  saved. 


4.  '.1.4.1  -  Check  2. 4. a.  -  The  CIC  is  validated  for  four 
^ilphahptir  rhprarters,  or  three  alphabetic  and  one  numeric 
character . 

Error  Condition  -  Not  a  valid  CIC,  one  listed  in 
LDMX  table,  or  not  enough  characters  in  the  CIC. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  CIC  FORMAT". 
See  Message  Error  Processing  for  the  appropriate  response. 


4.  .1.4.2  Check  2.4.b.  -  The  CIC  indicates  an  ADMS/ASC 
generated  pilot,  the  original  CIC  from  Format  Line  2  is  also 
validated  (dual  header  'only )  . 

Error  Ccnditlcn  -  No  valid  CIC  in  piloted  Format 
Line  2,  or  no  Format  Line  2  E:{ren3icn  present. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  FORMAT  LINE  2".  See  Message  Error  Processing  for  the 
appropriate  response. 

4. 4.1.4. 3  Check  2 . 4 . c .  -  The  CIC  "ZYVW"  is  detected, 
indicating  a  service  message. 

Error  Condition  -  None  -  Checks  are  made  during 
RI  validation  for  non  local  RIs,  and  if  present  no  further 
format  validation  is  done. 

Error  Resolution  -  N/A 


CIC  X. 


4.4.1.:. 

a  space, 


c*'iar„c’ 


4.4 . 1.5.1 
CIC  field. 


Check  2. 5. a.  -  Check  the  character  following  the 


Error  Condition  -  Any  character  other  than  a 


space , 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  CHARACTER  AITEH  CIC".  See  Message  Error  Processing  for 
the  appropriate  response. 

4. 4. 1.6  OricTinatincT  Station  Routing  Indicator  (OSRI)  Field. 

-  Following  the  separator  is  the  seven  character  OSRI  field. 
This  may  be  a  six  or  seven  character  Routing  Indicator  (RI) 
spaced  filled  to  seven  characters.  A  valid  OSRI  is  saved  for  a 
later  comparison  to  determine  if  the  message  is  a  duplicate. 
This  is  discussed  in  detail  later  in  the  document. 


4.  .1.6.1  Check  2. 6. a.  -  The  OSRI  is  validated  for  seven 

alphabetic  characters  beginning  with  an  "R". 

Error  condition  -  The  OSRI  begins  with  a 
character  other  than  "R"  or  contains  non-alphabetic  characters. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  OSRI".  See 
Message  Error  Processing  for  the  appropriate  response. 


4  . .  1 . 7  OricTinatina  Station  Serial  Number  (SSN)  Field .  - 

Immediately  follcwir.g  the  OSRI  is  the  SSN  field.  The  SSN  field 
is  validated  for  four  numeric  characters.  A  valid  SSN  is  saved 
for  later  comparison  with  the  Trailer  Station  Serial  Number 
(TSSN)  to  ensure  that  a  "straggler"  condition  does  not  exist. 
Straggier  chec-ljing  is  discussed  under  End-of -Message  validation. 
A  valid  SSN  is  used  along  with  the  OSRI  during  duplicate  message 
validation.  h  valid  SSN  for  FT,  LA,  KA,  and  NT  messages  is 
saved,  but  not  used  for  straggler  validation.  All  others  are 
used  for  straggler  checks. 


4.4-1-7.1  Check  2 . 7 . a .  The  SSN  field  is  validated  for  four 

numeric  characters. 

Error  Condition  -  The  SSN  is  not  numeric  or  four 
characters  in  length. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SSN".  See 
Message  Error  Processing  for  the  appropriate  response. 


4  .4  . 


■  r .  -  Z'r.c  SE'.i  is  compare.:  tr  tne  TEZ.  . 

Lrror  Condition  -  The  SSN  does  not  match  the  TSSN 
(Format  Line  15). 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 

"STRACJGLEIR  SSN  MISMATCH".  See  Message  Error  Processing  for  the 
appropriate  response. 


4 .A. 1.8  Separator .  -  The  character  following  the  SSN  must  be 

a  space. 


4. 1.8.1  •;  Check.  2 . 8 .  a  .  -  Check  the  character  following  the 

SSN  field. 

Error  Condition  -  Any  character  other  than  a 

space . 

Error  ResoluLiori 
service  position  with 

"INVALID  CHARACTER  AFTER  SSN". 
the  appropriate  response. 


-  The  message  is  rejected  to  a 
the  error  annotation 

See  Message  Error  Processing  for 


4. 4. 1.9  Time-of-File  (TOF)  Field.  -  The  TOF  field  is 
validated  for  seven  numeric  characters.  Procedurally ,  the  TOF 
field  is  composed  of  a  three  digit  Julian  date  (001-365/366)  and 
four  digit  time  (0000-2359)  and  range  checks  are  made.  The  TOF 
is  used'  along  with  the"  OSRI  and  SSN  in  duplicate  message 
validation,  which  will  be  discussed  later  in  the  document. 


4.  .1.9.1  Check  2 . 9 . a .  -  Check  the  TOF  field  for  seven 

.numeric  characters  in  the  appropriate  ranges. 

Error  Condition  -  The  TOF  is  not  numeric  or  seven 
characters  in  length. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INV.ALID  TOF".  See 
.Message  Error  Processing  for  the  appropriate  response. 


4.  .1.10  Security  Redundancy  Field  Separator.  -  Following 

the  TOF  field,  the  character  must  be  a  dash  or  hyphen  ( iTA2 
uppercase  "A")  signalling  the  start  of  the  Security  Redundancy 
field.  If  the  Security  Redundancy  separator  is  misplaced,  the 
message  could  be  a  pilot  or  a  data  pattern  message  (TC/AC).  In 
either  case  the  proper  fields  are  validated. 


is  noc  a  dasr 


or  a  oianK  ci.aracter. 


Error  Condition  -  Any  character  other  than  a  dash 

or  a  blank. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 

"INVALID  SEPARATOR  CHARACTER".  See  Message  Error  Processing  for 
the  appropriate  response. 


4.4.1.11  ■  Piloted  Message  Field.  -  When  the  separator  is  a 
blank  character  this  field  is  checked  to  determine  if  the 
message  contains  a  pilot  header  or  is  possibly  a  data  pattern 
message.  Should  the  message  contain  a  pilot  FL2  and  the  CIC 
equal  "ZZGW"  or  "IJJY",  the  pilot  FL2  is  stripped  and  a  search 
done  for  the  original  FL2. 
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Check  2. 11. a.  -  Check  for  "PLTS"  (terminally 
"Rxxx"  (switch  prepaied)  pilot  indicators. 


Error  Condition  -  Pilot  field  contains  data  other 
than  pilot  headers  and  the  message  is  not  a  data  pattern  (lAZZ) 
message . 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  PILOT/CARD  COUNT".  See  Message  Error  Processing  for 
the  appropriate  response. 


4. 4- 1-12  Record  Count  Field.  -  When  the  separator  is  a  blank 
character  and  does  not  contain  a  pilot  header,  this  field  is 
checked  for  valid  record  count  indicators. 


4.  .1.12.1  Check  2 . 12  .a .  -  Check  for  "MT.MS"  or  for  four 

valid  numerics. 


Error  Condition  -  Record  Count  field  contains 
data  other  than  "MTMS"  or  four  numeric  characters. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  PIL0T/CAJ5D  COUNT".  See  Message  Error  Processi.ng  for 
the  appropriate  response. 


l-rnac,  the  cr.ar  i  *^e>.-rity  P.eiur.^ancy  field  is 
validated  in  different  ways.  All  four  characters  of  the 
Security  Redundancy  field  must  be  identical  to  the  single 
security  character  previously  validated  (fourth  data  character 
of  the  header)  provided  the  message  is  not  addressed  to  an 
Allied  destination.  If  the  message  is  addressed  to  an  Allied 
destination,  the  last  two  characters  of  the  Security  Redundancy 
field  must  then  be  valid  transmission  release  codes  (TRCs). 
There  may  be  two  different  TRC  destinations  within  the  message 
and  both  RIs  must  be  in  Format  Line  2.  When  more  than  one  TRC 
is  indicated  they  have  to  be  arranged  in  alphabetical  order. 
Note  that  Format  Line  4  must  be  present  whenever  a  TRC 
indication  is  present  in  Format  Line  2. 

4.4.1.13.1  "•  Check  2 . 13 .  a .  -  Check  the  first  two  security 
characters  against  the  single  security  character  field. 

Error  Condition  -  The  first  two  characters  are 
not  identical  to  the  single  security  character  field. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"SECURITY  REDUNDACY  ERROR  -  F/L  2".  See  Message  Error 
Processing  for  the  appropriate  response. 


4. _. 1.13. 2  •  Check  2 . 1 3 . b .  -  The  last  two  characters  of  the 
Security  Redundancy  field  are  checked  to  see  if  they  are  valid 
TRCs,  or  security  characters. 

Error  Condition  -  The  two  characters  fail  the 
validation  check  (not  TRC  characters,  or  security  characters). 


Error  Resolution  -  The  messaae  is  reiected  to  a 


service  positio.n  with  the  error  a 
"SECURITY  REDUNDAiUCY  ERROR  -  F/L  2".  See  Message 
Processi.ng  for  the  appropriate  response. 


annotation 


4.  .1.14  Start  of  Routing  (SOR)  Field.  -  After  the  Security 
Redundancy  checks  are  complete,  the  SOR  field  is  then  validated. 
This  field  is  a  two  character  field  containina  dash  dash  (--). 


4.4.1.14.1 
dash  dash  (--) 


Check  2. 14. a.  -  The  SCR  field  is  validated 


Error  Condition  -  The  SOR  field  contai.ns 
characters  other  than  a  double  dash  (--). 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"li'.T/ALID  START  OF  ROUTING".  See  .Message  Error  Processing  for 
the  appropriate  response. 


".dicatcr  (HI  )  Fie 


4.4-2. 1  Routing  Indicator  (RI)  Field.  -  The  RI  is  the 
"address"  of  a  message.  An  RI  may  not  be  split  by  either  spaces 
or  by  an  End  of  Line  (EOL)  sequence  in  any  instance.  The  RI  is 
examined  for  the  proper  form,  which  begins  with  an  "R"  and 
ranges  from  four  to  seven  alphabetic  characters.  A  separator  is 
provided  between  each  RI  unit.  Format  Line  2  may  contain  up  to 
four  seven  character  RIs,  seven  four  character  RIs,  or  any 
combination  thereof,  not  to  exceed  the  69  character  line  length, 
with  up  to  eight  RIs  on  Format  Line  2  continuation  lines.  The 
RIs  are  terminated  when  the  End  of  Routing  sentinel  which  is  a 
period  ( . )  is  encountered.  During  RI  validation  the  RIs  are 
examined  for  Broadcast  (BCST) ,  Over-the-Counter  (OTC),  or  Other 
to  determine  the  RI  type.  It  is  the  RI  characteristics  (i.e., 
OTC,  Other)  found  here  that  influence  to  what  extent  TARE,  FL7, 
8,  or  9  lines  will  be  examined  and  validated. 

Since  the  I-S/A  AMPE  will  not  receive  RIs  for 
local  broadcast  to  the  fleet,  bnnartrast  prnrpssing/val idation 
will  not  be  addressed  further. 


4 .4 . 2 . 1 . 1  Check  3.1. a.  -  The  first  character  of  the  RI  must 

begin  with  an  "R" . 

Error  Condtion  -  First  character  of  the  RI  is  not 

an  "R" . 

■0 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  RI".  See 
Message  Error  Processing, for  the  appropriate  response. 


4. ^.2. 1.2  Check  3 . 1 . b .  -  The  RI  must  contain  four  to  seven 

characters. 

Error  Condition  -  The  RI  contains  more  than  seven 
characters,  or  the  RI  contains  invalid  characters. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  RI".  See 
Message  Error  Processing  for  the  appropriate  response. 


4.4. 2. 1.3 

Check  2 

.l.c.  -  Is  the  intended 

RI 

destined 

for 

AUTODIN . 

received  from 

Error 

AUTODIN 

Condition  -  Either  a  CARP 
,  or  the  message  contains 

or 

an 

non-local 
invalid  RI. 

RI 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"ILLEGAL  ROUTING  INDICATORS:  X:<XXXXX'' .  See  Message  Error 
Processing  for  the  appropriate  response. 
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-i 


accOiiiLu.ir.ec  i.; 


Error  Condition  -  A  valid  Allied  RI  is  found  and 
there  is  no  associated  TRC. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  TRANSMISSION  RELEASE  CODE  FOR  See  Message  Error 
Processing  for  the  appropriate  response. 


4.^. 2. 1.5  Check  3 . 1 . e .  -  The  seventh  character  of  a  RIXT  RI 
is  "Y  or  Z"  or  not  alphabetic. 

Error  Condition  -  The  seventh  character  of  the 
RIXT  RI  is  a  "Y  or  Z". 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  7th  CHAR  IN  RIXT  RI".  See  Message  Error  Processing  for 
the  appropriate  response. 

4. 4. 2. 1.6  Check  3 . 1 . f .  -  Format  Line  2  contains  a  Modified 
ACr  126  "SOU"  RI  and  at  least  one  other  valid  RI  has  been 
identif ied . 


Error  Condition  -  Either  Format  Line  2  is 
incorrectly  formatted  or  this  message  contains  a  Modified  ACP 
126  "SUU"  RI  and  it  should  not. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"MOD  AC?  126  MSG  IDENTIFIED  AS  J.\::.\P  12S".  See  Message  Error 
Processi.ng  for  the  appropriate  response. 


4  , .  2 . 1 . 7  Check  3 . 1 .  a .  -  End  of  Routing  sentinel  detected 

without  identifying  a  Routing  Indicator. 

Error  Condition  -  No  Routing  Indicator  or  one 
which  exists  is  illegal. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 

"NO  VALID  RI  OR  ILLEGAL  RI".  See  Message  Error  Processing  for 
the  appropriate  response. 


“  Che  r  c _ j  .  1  .  h  ■  -  I:--  rh.  r.aj  no  primary  delivery 

responsibility,  and  is  valid. 

Error  Condition  -  The  Format  Line  2  RI  is 
identified  as  a  "SVC"  RI . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 

"PROTECT  FOR  ADDRESSEIE  OF  See  Message  Error  Processing  for 

the  appropriate  response. 

4.J.2.2  End-of -Routing  Field.  -  The  JANAP  format 

End-of -Routing  (EOR)  consists  of  a  period  (.). 


4.  .2.2.1  Check  3. 2. a.  -  Validate  that  there  is  a  valid  EOR. 

Error  Condtion  -  The  last  field  in  Format  Line  2 
contains  an  invalid  EOR  sentinel. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  “INVALID  RI”.  See 
Message  Error  Processing  for  the  appropriate  response. 


4.4.3  JANAP  Validation  of  "DE"  Line.  - 


4.  .3.1  Format  Line  3  (FL3)  Validation.  -  This  format  line 

is  being  discussed  because  of  the  ability  of  ACP  127  originated 
messages  to  enter  an  ASC,  be  converted  to  a  JANAP  128  message, 
and  thereby  passed  on  to  other  AUTODIN  subscribers.  These 
messages  will  be  identified  by  their  Language  Media  Formats 
(LMFs).  Format  Line  3  (FL3)  is  positioned  between  FL2  and  FL4 , 
and  contains  the  prosign  "DE" ,  the  ACP  127  OSRI,  SSN,  and  Time 
cf  File  (TOF) .  Information  found  to  be  valid  on  this  line  is 
scored  for  subsequent  duplicate  m.essage  and  recall  processing. 

Valid  FL3  structures  are : 

DE  RxxxAAA  NNNN  JJJHHMM 

1  ...  2  3  4 

1.  Prosign. 

2.  Originating  Station  Routing  Indicator  (OSRI), 
starts  with  an  ”R"  and  is  4  to  7  alphabetic 
characters  long. 

3.  Originating  Station  Serial  Number  (SSN),  may 
exist  in  the  following  forms  (N=numeric, 
A=alphabetic ) . 

A .  #NNNN 

B .  NNNN 

C .  NNNA 

D.  NNN 

4.  This  field,  the  Time  of  File  (TOF),  is 


values 


C  ^ »  t  '  V  ^  7^  I*  ’ 

(jjJ  =  Ju-tiaji  j  ~  Vci^ues  Ov.j,”3co, 

HH  =  Hours  -  values  00-23  , 

MM  =  Minutes  -  values  00-59,  DD  =  Day  - 
00-31,  Z  =  Zulu  Time  Indicator). 

A.  JJJHHMM 

B.  DD/HHMMZ 


Validation  of  the  SSN  and  TOF  fields  are  not 
exacting  and  will  not  cause  errors  if  not  in  the  proper  format. 


4. 4- 3. 1.1  Check  4.1. a.  -  Ehsure  that  more  information  exists 

on  FL3  besides  the  prosign  "DE  ". 

Error  Condition  -  Prosign  "DE  "  found  but  no 
other  information  exists. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  FL3".  See 
Message  Error  Processing  for  the  appropriate  response. 

4. ^.3. 1.2  ■  Check  4.1.b.  -  Check  for  a  valid  OSRI . 

Error  Condition  -  The  OSRI  found  does  not  begin 
with  an  "R",  or  is  not  4  to  7  alphabetic  characters  long. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  OSRI  FL3". 
See  Message  Error  Processing  for  the  appropriate  response. 


4.4.4  JANAP  Validation  ot  the  Security  Line.  - 


4 .  .j. .  4 . 1  Security  Line  (FL4).  -  Following  the  EOR ,  original 
FL2 ,  or  FL3  processing  the  next  field  to  be  validated  is  the 
security  line,  format  line  four.  If  a  pilot  header  is  present, 
FL4  must  follow  the  original  FL2  or  FL3.  For  all  messages 
requiring  FL4 ,  the  first  four  characters  following  the  EOR  must 
be  the  operating  signal  "ZNR"  or  "ZNY"  followed  by  a  space. 
When  it  is  determined  that  FL4  is  present,  the  remaining 
security  fields  are  processed.  The  first  of  these  is  five 
characters  in  length  and  may  consist  of  five  redundant  security 
characters,  or  three  redundant  security  characters  and  two 
transmission  release  code  (TRC)  characters.  Following  this  five 
character  field  and  separated  by  a  slash  (/),  may  be  from  one  to 
four  optional  special  handling  designator  (SHD)  fields 
(separated  by  a  slash)  or  a  SPECAT  Release  Code  (SRC);  each  of 
which  consists  of  a  five  character  repetition  of  an  SHD 
character.  There  nay  be  only  one  set  of  SRC  an  may  not  be  mixed 
with  messages  containing  TRCs  or  other  SHDs .  Following  the 
security  field,  separated  by  a  space,  may  be  operating  signals, 
which  may  be  followed  by  a  space  and  misroute  information  if  the 
Z-signal  is  one  of  "ZOV",  (Z-signal  processing  other  than  "ZOV" 
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4.4 -4.1.1  Check  5 . 1 . a .  -  The  first  four  characters  of  FL4 
are  checked  to  see  if  they  contain  "ZNR"  or  "ZNY"  a’' d  a  space. 

Error  Condition  -  The  first  three  characters  are 
not  "ZNR"  or  "ZNY"  and  followed  by  a  space;  "ZNY"  and  a  space 
is  used,  hut  the  FL2  security  redundancy  field  is  "UUUU";  or 
"ZNR"  and  a  space  is  used,  but  the  FL2  security  redundancy  field 
is  other  than  "UUUU". 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  FORMAT  LINE 
4".  See  Message  Error  Processing  for  the  appropriate  response. 

4. c".  4. 1.2  Check  5 . 1 .  b .  -  The  first  three  characters  of  the 
security  field  are  validated  to  be  redundant  and  must  match  the 
security  redundancy  field. 

Error  Condition  -  The  characters  are  not 
redundant  or  du  not  march  those  in  FL2. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SECURITY  ON 
F0.R*‘4AT  LINE  FOUR".  See  Message  Error  Processing  for  the 
appropriate  response. 


4  .4.  4.1..  3  Check  5 . 1 .  c  .  -  The  next  two  characters  are  checked 
for  security  redundancy  or  valid  TRCs. 

Error  Condition  -  The  FL2  security  redundancy 
field  does  not  indicate  TRCs  required,  and  the  characters  in 
these  two  positions  are  other  than  security  redundant 
characters . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SECURITY  ON 
FORMAT  LINE  FOUR".  See  Message  Error  Processing  for  the 
appropriate  response. 


4  .4  .4.1.4 


Check  5 


-  The  two  characters  are  invalid,  not 


redundant  if  only  one  TRC  is  required,  not  in  alphabetical  order 


more  than  one  TRC  is  reauired,  or  do  not  match  those  in  FL2 


Error  Condition  -  The  TRC  characters  are  invalid, 
not  redunda.nt  if  only  one  TRC  is  required,  or  not  in 
alp.habetical  order  if  more  tha.n  one  TRC  is  required. 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "F/L4  TOC  NOT  EQUAL 
TO  F/L2  TRC".  See  Message  Error  Processing  for  the  approoriate 


redundancy  /  TRJ  iield,  a  checr.  is  made  tor  the  Special  Kandl*n4 
Designator  (SHD)  sentinel,  a  slash  (/),  or  a  space. 

Error  Condition  -  Any  character  other  than  a 
slash  (/),  a  space  or  a  valid  end-of-line  sequence  following  the 
previous  field. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "ILLEGAL  CHARACTEKS 
ON  FORMAT  LINE  FOUR".  See  Message  Error  Processing  for  the 
appropriate  response. 


4. 1. 4. 1.6  Check  5 . 1 . f .  -  The  SHD  sentinel  is  found,  check 
the  next  five  characters  for  redundancy  and  they  must  be  valid 
SHD  category  characters  as  specified  in  ACP  117. 

Error  Condition  -  The  five  characters  are  not 
redundant,  not  a  valid  SHD  category,  SHDs  found  number  more  than 
four,  or  the  classification  of  the  message  is  below 
CONFIDENTIAL. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  OR  DUPLICATE 
SHD  ON  F/L  4".  See  Message  Error  Processing  for  the  appropriate 
response. 

4. 4. 4. 1.7  Check  S.l.g.  -  If  the  SHJ3  sentinel  is  found,  the 
input  channel /posi tion  is  checked  to  see  if  it  is  authorized  to 
enter  SHDs. 

Error  Condition  -  Special  handling  is  required 
for  the  message  and  the  input  cha.nnel/position  is  not  authorized 
to  enter  the  SHD. 

Error  Resolution  -  The  message  is  rejected  tc  a 
service  position  with  the  error  an.notat ion  "SPECIA.L  HANDLING 
REQUIRED".  See  Message  Error  Processing  for  the  appropriate 
response . 

4.  .4.1.8  Check  5 . I . h .  -  If  another  SHD  sentinel  (/)  is 
found,  the  next  field  is  validated  in  the  same  m.anner  as  the 
first.  If  a  valid  SRC  is  detected  a  check  is  made  to  ensure 
there  are  no  transmission  release  code(s)  or  SHDs  in  the 
message . 

Error  Condition  -  The  message  contains  TRC(s)  and 
a  SRC  in  FL4 ,  or  the  message  contains  an  invalid  SRC  or  the  SRC 
does  not  agree  with  the  message  classification,  or  SRC  is 
present  with  other  SHDs. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SRC  ON 
FORMAT  LINE  FOUR"  or  "ILLEGAL  CLASS  WITH  SRC  OR  SHD".  See 
Message  Error  Processi.ng  for  the  appropriate  response. 


^  ^  ■  r  .  ■  .  1  -  ...e  mej  si::-  u  i"-.- 

a:id  n  ShL  ser.cinej.  is  deieccei,  FLi  ei'iecL^c.  ic  ccr.ia.in  j. 
space  lollowing  Che  security  redundancy  field  and  then  the 
Z-signal  "ZOV  followed  by  the  misroute  information. 

Error  Condition  -  FL2  processing  indentified  the 
message  as  a  "ZOV"  and  FL4  does  not  contain  the  Z-signal. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  ZOV  -  F/L 
4".  See  Message  Error  Processing  for  the  appropriate  response. 

4.4.4.1.10  Check  5 . 1 . i .  -  If  FL4  contains  the  Z-signal  "ZOV" 

followed  by  a  space,  the  next  position  is  validated  to  be  the  RI 
of  the  originator. 

Error  Condition  -  The  RI  does  not  begin  with  an 
"R",  or  does  not  match  the  OSRI  found  in  FL2 . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  puslLlun  with  the  error  annotation  "ZOV  OSRI  DOES  NOT 
.MATCH  F/L  2  OSRI".  See  Message  Error  Processing  for  the 
appropriate  response. 


4.4  .4.1.11  Check  5 . 1 . k .  -  If  the  Reroute  OSRI  is  valid,  then 
the  next  four  characters  are  validated  for  four  numeric 
characters  and  that  they  are  followed  by  "R/R”  or  "Reroute  OF". 

Error  Condition  -  Non-numeric  characters  found  in 
the  SSN  field,  or  the  Reroute  caveat  does  not  follow  the  SSN. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  cosition  with  the  error  annotation  "SEQUENCE  SEI^I.4.L 
NUMBER  IS*  NOT  NUJdEEIC  ON  F/L  4".  See  Message  Error  Processing 
for  the  arcrcrriate  response. 


4. ..4. 1.12  Check  5.1.1.  -  Check  the  OSRI/SSN  fields 

following  the  Reroute  information. 

Error  Condition  -  The  RI  does  not  begin  with  an 
"R"  or  contain  the  correct  number  of  characters. 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  a.nnotation  "INV.RLID  RI  ON  FORMAT 
LINE  FOUR".  See  .Message  Error  Processing  for  the  appropriate 
response . 


*  C-  - 


secure: 


r  cciunCL 


operating  or  passing  instructions  nay  be  present.. 


Error  Condition  -  None  of  the  characters 
remaining  on  FL4  resemble  any  operating  signals  or  TARE 
instructions . 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  TARE  LINE". 
See  Message  Error  Processing  for  the  appropriate  response. 


4 .4  . 5  JANAP  Validation  of  FL4  Continuations  (FL4/E).  -  FL4/E 
may  contain  TARE  instructions  or  operating  signals.  Each  will 
be  discussed  in  the  following  paragraphs. 


4.^.5.! 
the  start 
line  2.  If 
allowed : 

T  (Alone) 

T  Short  Title  or  T-Short  Title 

T  Zl-JL  Short  Title 

When  T  (Alone)  is  found,  the  presence  of  any 
other  format  is  illogical  and  constitutes  an  error. 

T  ( Alone ) .  T  (Alone)  indicates  full  routing 
responsibility . 

T  Short  Title  or  T-Short  Title.  Eased  on  short  title 
delivery  characteristics,  if  the  delivery  is  not  local,  then  the 
tare  format  is  valid.  For  local  addees  (i.e.,  CTO,  however,  an 
RI  is  retrieved  for  that  short  title  frsm  the  data  base  and 
compared  against  RIs  existing  in  FL2.  If  a  match  occurs, 
delivery  will  be  made  to  that  specific  short  title,  otherwise  no 
delivery  is  made  and  TARE  line  is  valid. 

T  ZWL  Short  Title.  For  these  cases,  the  short  title 
is  validated  and  saved  for  later  processing  during  forr.at  line 
seven  and  eight  validation. 

If  the  message  has  multiple  RIs,  the  following  are 
groupings  of  tare  instructions  allowed: 

RXXExxx  T  Short  Title 

PdOCXxxx  T-Short  Title 

T  ZWL  Short  Title 

If  a  side-routed  tare  does  not  have  the  local 
communication  stations  RI ,  it  is  simply  validated. 

If  a  message  is  misrouted  (indicated  by  the  presence 
of  "ZCV")  and  contains  "T  SHORT  TITLE"  (or  any  variation');  then 
message  routing  will  be  handled  lAW  the  tare  instructions  o.nly. 


Tare  Instruction  Search  (FL4/E).  -  A  test  is  made  at 
of  tare  processing  to  see  how  many  RIs  are  in  format 
only  one  RI  was  found,  the  following  items  are 


messages  which  do  not  contain  tare  instructions  and  FL2  hcis  only 
one  RI ,  the  message  routing  will  be  based  on  format  line  seven 
or  eight  processing. 

In  all  cases,  as  was  mentioned  earlier,  PLA  or  short 
title  validation  will  only  be  done  if  FL2  contained  a  Local  RI, 
and  it  should  be  kept  in  mind  when  reading  about  PLA  or  short 
title  verification. 


4.4. 5. 1.1  Check  6 . 1 .  a .  -  The  format  line  four  extension  is 
validated  for  proper  format,  FL2  addees,  and  illegal  short  title 
combinations . 

Error  Condition  -  If  the  line  cannot  be 
identified  as  a  valid  tare  line;  the  short  title  is  a 
collective;,  or  a  T-ZWL  format  is  included  in  a  misrouted 
message . 

Error  Resolution  ~  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  TARE  LINE". 
See  Message  Error  Processing  for  the  appropriate  response. 

4. 4. 5. 1.2  Check  6 . 1 . b .  -  The  short  title  to  be  searched  for 
contains  valid  characters. 

Error  Condition  -  The  short  title  contains  an 
unrecognizable  combination  of  characters. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHORT  TITLE  NOT  IN 
DATA  BASE".  See  Message  Error  Processing  for  the  appropriate 
response . 

4.4. 5.1.3  Check  S.l.c.  -  TARE  instruction  appears  in  the 
following  format  or  variation  thereof  whereby  the  RI  sideroute 
is  present:  Rxxxxxx  T  SHORT  TITLE/SHORT  TITLE 

Error  Condition  -  A  valid  Local  short  title  is 
found,  an  RI  retrieved  from  the  LDIiM  to  use  as  a  search  argument 
against  FL2  RIs,  no  natch  was  found  and  the  sideroute  does  not 
match  the  LDMZ  retrieved  RI  either. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  a.nnotation  "INCORRECT  SIDEROUTE 
FOR  XI'fXX .  .  . XZX "  .  See  Message  Error  Processing  for  the 
appropriate  response. 

Error  Condition  -  Two  or  more  short  titles  on  the 
same  T.ARE  line  which  are  not  separated  by  a  slash  (/). 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHORT  TITLE  NOT  IN 
DATA  EASE".  See  Message  Error  Processing  for  the  appropriate 
response. 
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local  deliveries. 

Error  Condition  -  The  message  contains  more  than 
500  Protect  (local  RIs)  addees. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "TOO  MANY  OTC  ADDEES 
TO  PROCESS".  See  Message  Error  Processing  for  the  appropriate 
response . 

4. 4. 5. 1.5  Check  6 . 1 . e .  -  Ensure  all  Local  "T  ZWL"  short 

titles  are  processed. 

Error  Condition  -  The  maximum  number  of  "T  ZWL" 
short  title  identifiers  is  reached. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "CANNOT  PROCESS  ALL 
'T  ZWL'.  MAX  PEIR  MSG:  XX"  where  XX  represents  the  numerical 
maximum . 


4.^  .5.2  Operating  Signals  (Z-Sianal)  Processing.  -  Operating 
signals  or  Z-signals  as  they  are  called  may  be  found  on  format 
line  4,  format  line  4  extensions  or  format  line  5.  Whenever  a 
potential  Z-signal  is  detected,  control  is  passed  to  the 
appropriate  processing  module  for  validation.  Z-signal 
processing  is  discussed  in  three  parts:  Initial  "Z"  Signal 
Validation;  ZPW  Validation;  and  Other  "Z"  Signal  Validation. 

All  operating  signal  validations  are  passive,  to 
the  extent  that  just  because  a  word/ trigraph/etc .  may  start 
with  a  "Z"  it  dees  not  m.ean  that  it  must  be  a  "Z"  signal  and  no 
errors  are  given  based  solely  on  a  "Z"  bei.ng  present. 

Initial  "Z"  Signal  Validation.  Wnen  a  pote.ntial 
Z-signal  is  identified,  the  first  three  characters  of  the 
Z-signal  are  verified  for  alphabetics  and  the  fourth  character 
is  verified  to  be  either  numeric  or  blank. 


ZPW  Validation.  l-Jhenever  the  Z-sig.nal  "ZPW"  is 
identified  the  remiaining  data  is  verified  to  be  a  six  digit 
numeric  Date-Time-Group  followed  by  the  letter  "Z". 


Other  "Z"  Signal  Validation. 
"ZN.M"  are  invalid.  For  Z-signals  other 
scanned  for  the  corresponding  Z-signal 
appropriate  flag  is  set.  Wnenever  the 
ZEL,  ZFG,  ZFF4,  SFF5 ,  ZFF6 ,  ZFHl ,  ZFH2 ,  ZFH 


Z-signals  "2XY"  and 
than  "ZPW"  a  table  is 
and  if  found  the 
Z-signals:  ZDX,  ZDG , 

3,  ZUI,  or  ZDS  are 


identified  the  message  is  directed  to  a  service  position  as  well 


as  the  primary  delivery  indicated  in  FL2  routing. 
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for  proper  format. 

Error  Condition  -  None  -  The  Z-signal  does  not 
contain  alphabetic  characters  in  the  first  three  positions,  or 
the  fourth  character  is  not  numeric  or  a  space. 

Error  Resolution  -  N/ A 


4.4 -5. 2. 2  Check  6 . 2 . b .  -  The  Z-signal  is  one  of  "ZPW". 

Error  Condition  -  The  "ZPW"  Z-signal  is 
identified  and  the  Date-Time-Group  field  contains  invalid 
characters,  or  the  line  does  not  end  with  a  "Z". 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "BAD  ZPW  TIME".  See 
Message  Error  Processing  for  the  appropriate  response. 


4.4 -5.2.3  Check  6.2.c.  -  The  Z-signal  field  contains  the 

characters  "ZNM" . 

Error  Condition  -  The  "ZNM"  Z-signal  is  not 
permitted  in  the  message. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "ZNM  ILLEGAL".  See 
Message  Error  Processing  for  the  appropriate  response. 

4. 4. 5. 2. 4  Check  6.2.d.  -  The  Z-signal  field  contains  the 

characters  "ZXY" . 

Error  Condition  -  The  "ZXY"  Z-signal  is  detected 
and  requires  delivery  be  made  to  the  addresse  indicated  by  the 
fourth  character  of  the  Z-signal. 

Error  Resolutio.n  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "ZXY  SIGNAL  FOUND". 
See  Message  Error  Processing  for  the  appropriate  response. 

4.  .5.2.5  Check  6 . 2  ■  e .  -  A  Z-signal  is  detected  without 

format  errors,  but  does  not  match  a  specific  Z-signal  requiring 

addition  action. 

Error  Condition  -  .None  -  The  Z-signal  is 
validated  for  proper  format  and  stored  as  apart  of  the  message. 

Error  .Resolution  -  H/A 


4.4.6 


J.^NAP  Validation  of  Date-Time-Group  (DTG)  Line, 


4.^  .6.1  Date-Tirne-Group  (FL5).  -  Following  validation  of 
fromat  line  four  extensions'  (tare  instructions  and  operating 
signals),  the  next  line  validated  is  the  Date-Time-Group.  The 
Date-Time-Group  consist  of  the  Precedence  field(s),  the  actual 
day,  hour,  and  minutes  of  the  message,  a  terminator,  the  month 
field,  and  a  year  field.  Format  line  5  may  also  contain 
operating  signal(s)  if  the  message  warrants  them.  Operating 
signal  processing  has  been  previously  discussed  in  this 
document . 


VALID  FORMAT  LINE  5  STRUCTURE; 

P  DDHRMMZ  MON  YR 
PI  DDHHMMZ  MON  YR 
P  I  DDHHMMZ  MON  YR 

LEGEND : 

P  =  ACTION  PRECEDENCE 
I  =  INFO  PRECEDENCE 
DD  =  VALID  DAY  -  RANGE  01  THRU  31 
HH  =  VALID  HOUR  -  RANGE  00  THRU  23 
MM  =  VALID  MINUTE  -  RANGE  00  THRU  59 
Z  =  ZULU  TIME  DESIGNATOR 
,  MON  =  VALID  MONTH 
YR  =  NUMERICAL  YEAR 

E)ach  of  the  aforementioned  structures  may  contain 
operating  signals  and  does  not  require  "YR"  if  the  message  was 
input  from  .J'.UTODIN. 


4. 4. 6. 1.1  Check  7 . 1 . a .  -  Check  the  first  character  of  the 
DTG  for  a  valid  precedence. 

Error  Condition  -  There  is  only  one  precedence  in 
format  line  5  and  it  does  not  equal  the  FL2  precedence. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "PRECEEEINCE  ERROR  ON 
F/L  5".  See  Message  Error  Processing  for  the  appropriate 
response . 

4. 1.6. 1.2  Check  7 . 1 . b .  -  Validate  the  second  position  of  the 
DTG  for  a  space  or  valid  INFO  precedence. 


fc".  •• 
t-.v . . 


Error  Condition  -  An  illegal  INFO  precedence 
character  follows  the  action  precedence  character;  or  a 
character  other  than  a  space  follows  the  second  precede.nce 
character  of  the  DTG  field. 
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servict  posiLic.i  wi;:n  i 
PRECEDENCE  FIELD  ON  F/L  5' 
the  appropriate  response. 
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See  Messaae  Error  Processinq  for 


4.4. 6. 1.3  Check  7 . 1 . c .  -  The  third  position  in  the  DTG  is 
validated  for  a  dual  precedence  or  the  beginning  of  the 
Date-Time-Group  field. 

Error  Condition  -  If  the  third  character  is  not 
an  alphabetic  precedence  character  less  than  the  first 
precedence  in  FL5,  a  numeric  character  indicating  the  first 
character  of  the  Date-Time-Group,  or  a  space  and  the  FL5 
structure  is  "PI  ". 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  DTG  ON  F/L 
5".  See  Message  Error  Processing  for  the  appropriate  response. 


4 .4 . 6. 1.4 
DTG  field. 


Check  7 . 1 . d .  -  Range  checks  are  performed  on  the 


Error  Condition  -  The  six  characters  following 
the  precedence  field  and  that  start  in  the  correct  position  are 
not  numeric;  the  day  portion  is  zero  or  greater  than  31;  the 
hour  portion  is  greater  than  23;  or  the  minute  portion  is 
greater  than  59. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  DTG".  See 
Message  Error  Processing  for  the  appropriate  response. 


4. 4. 6. 1.5  Check  7 ■ 1 ■ e .  -  The  DTG  digits  are  valid  numerics 
with  the  specified  range  and  ends  with  a  "Z". 

Error  Condition  -  The  Date-Time-Group  field  ends 
with  a  character  other  than  a  "Z". 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  Z  FOR  ZULU  ON  F/L 
5".  See  Message  Error  Processing  for  the  appropriate  response. 

4. 4. 6. 1.6  Check  7 . 1 . f .  -  A  valid  separator  must  follow  the 
Date -Time -Group . 

Error  Condtion  -  The  character  following  the  "Z" 
field  of  the  DTG  is  not  a  soace. 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  BLANK  AFTEP.  DTG 
FIELD  ON  F/L  5".  See  Message  Error  Processing  for  the 
appropriate  response. 
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is  validated  for  t.'.e  -pp.^priate  content. 

Error  Condition  -  The  characters  identified  in 
the  month  field  of  FL5  do  not  match  any  of  the  valid  twelve 
months . 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  MONTH  ON  F/L 
5".  See  Message  Error  Processing  for  the  appropriate  response. 

4. 4. 6. 1.8  Check  7.1.h.  -  If  the  month  field  is  valid  it  must 

be  followed  by  a  valid  separator. 

Error  Condition  -  The  character  following  the 
month  field  is  not  a  space. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  BLANK  AFTER  MONTH 
ON  F/L  5".  See  Message  Error  Processing  for  the  appropriate 
response . 

4. 4. 0.1. 9  Check  7 . 1 .  i  .  -  Messages  not  entered  from  AUTODIN 

require  the  year  field  to  be  present  in  FL5. 

Error  Condition  -  The  message  did  not  enter  the 
system  from.  AUTODIN  and  does  not  contain  a  year  in  FL5. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "YEAR  MISSING  ON  THIS 
F/L  5".  See  Message  Error  Processing  for  the  appropriate 
response . 

4.1.6.1.10  Check  7 . 1 . j  .  -  If  the  year  field  contains  data  it 

is  checked  for  a  valid  year. 

Error  Condition  -  Tne  year  field  contains  data 
and  it  is  not  numeric  data. 

Error  Resolution  -  The  m.essage  is  rejected  to  a 
service  position  with  the  error  annotation  "YEAR  IS  NOT  NUMERIC 
ON  F/L  5".  See  .Message  Error  Processing  for  the  appropriate 
response . 


JANAP  Validaticn  of  Originator  (FL6)  Lines.  - 


4.4.7 


reterrea  to  as  FLd  ,  is  veriiied.  to  ensure  it  is  witnin  the 
correct  character  limits;  and  if  it  exist  in  the  Data  Base. 
For  local  LDMX  processing  there  are  two  types  of  short  titles: 
a  Protect  Short  Title  and  a  Guard  Command  Short  Title.  In 
either  case,  the  LDMX  performs  special  message  distribution  and 
backrouting  dependent  upon  whether  or  not  a  Protect  or  Guard 
Short  Title  is  found. 


4. 4. 7. 1.1  Check  8 . 1 . a .  -  A  search  is  made  to  find  the  short 

title  in  the  database. 

Error  Condition  -  The  short  title  is  not 
contained  within  the  Data  Base. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHORT  TITLE  NOT  ON 
DATA  BASE".  gee  Message  Error  Processing  for  the  appropriate 
response . 

4.4.8  JANAP  Validation  of  Action/ Inf ormation  Lines.  - 


4. 4. 8.1  Format  Line  7  8  (FL7/8)  Processing.  -  The 

processing  of  FL7/8  requires  that  the  short  title  first  be 
isolated.  To  do  this,  it  is  determined  if  the  short  title  is 
siderouted  and  whether  it  is  processing  a  format  line  containing 
the  prosign  "TO"  or  "INFO".  When  the  prosign  is  present,  it  is 
skipped  and  validation  starts  with  the  sideroute  search. 
Sideroutes  consist  of  RIs,  ZEIN,  ZEINl ,  or  ZEIN2  followed  by  a 
slash  (/).  Should  the  line  contain  "ZDI"  in  any  of  the 
aforementioned  formats,  no  Short  Title  validation  is  done. 

Format  Line  seven  or  eight  may  contain  a  single 
sideroute  or  dual  sideroutes.  In  order  to  be  classified  as  a  RI 
sideroute,  it  must  begin  with  the  character  "R" ,  be  between  four 
and  seven  alphabetic  characters  in  length,  and  end  with  a  slash 
(/).  Once  the  RI(s)  have  been  identified  they  are  saved  for 
later  processing  and  the  short  title  has  now  been  isolated  for 
processing . 


Once  the  short  title  is  isolated,  delivery 
requirements  for  the  short  title  are  pursued.  Delivery  to  local 
(OTC)  short  titl'fes  is  based  upon  a  FL2-FL7  or  FL2-FL8  RI 
correlation.  This  condition  would  only  occur  for  RIs  identified 
as  OTC  Rxx.xSCC.  The  exceptions  will  be  discussed  later. 

When  short  title  processing  is  required,  the 
delivery  characteristics  (i.e.,  OTC,  etc.)  are  determined.  If 
the  short  title  is  OTC,  the  short  title's  RI  retrieved  from  the 
data  base  is  based  upon  the  message  classification,  and  that  RI 
is  used  for  the  FL2-FL7  or  FL2-FL8  RI  correlation.  Should  the 
result  of  the  FL2-FL7/8  RI  correlation  be  positive  the  short 
title  is  delivered  to.  If  negative,  and  the  short  title  w^»s 
siderouted,  then  the  sideroute  is  compared  against  the  retrieved 
data  base  RI.  Should  these  not  match,  it  is  possible  that  the 


n  no 


5hcro  tiole  was  incorrecul’  sid-ioa^aa  or  tne 
garbled .  In  either  case,  service  action  is  required.  : 
sidercute  matches  or  the  short  title  was  not  siderouted,  oh_ 
delivery  is  made  to  that  specific  short  title. 

Again,  FL2  RI  characteristics  are  used  to  key 
short  title  processing-  If  FL2  contains  a  collective  RI , 
RxxxSCC,  or  an  OTC  RI  then  short  title  processing  is  desired. 
Figure  4. 4. 8-1  is  a  delivery  decision  table  based  on  a  one  to 
one  comparison. 


DELIVERY  DECISION  TABLE 


If  FL2  contains  an  RI  which  is: 

S ideroute / Short  Title  Non-Local  PTC  RxxxSCC 

a.  =  SIDEROUTE  b.  =  SHORT  TITLE 


a . 

GARBLED 

DR 

b. 

GARBLED 

V 

V 

a . 

GARBLED 

DR 

b. 

NON-LOCAL 

(AUTODIN) 

V 

V 

a . 

GARBLED 

DR 

b. 

OTC 

D 

V 

a . 

NON-LOCAL 

(AUTODIN) 

DR 

b. 

GARBLED 

V 

V 

a . 

NON-LOCAL 

(AUTODIN) 

DR 

b. 

NON-LOCAL 

(AUTODIN) 

N 

N 

a . 

NON-LOCAL 

(AUTODIN) 

DR 

b. 

OTC 

D 

N 

a . 

RxxxSCC 

DR 

b. 

ANY 

i.« 

D 

a . 

ZEN 

DR 

b. 

ANYTHING 

N 

N 

a . 

OTC 

DR 

b. 

G.ARELED 

r  y 

V 

a . 

OTC 

DP. 

b. 

NON-LOCAE 

(AUTODIN) 

s 

N 

a . 

OTC. 

DR 

b. 

OTC 

D 

fT 

A  • 

C  =  CONTINUE  (no  delivery  responsibility) 

OP.  =  DELIVER  TO  FL2  RI  LRN  WITHOUT  PLA  LOOKUP 
N  =  NO  DELIVERY  TO  THAT  SPECIFIC  SHORT  TITLE  EASED  UPON 
FL7/8-FL2  RI  CORRELATION 

D  =  DELIVER  TO  SHORT  TITLE  LRN  IF  RI  IN  FL2  .‘LYTCHES 
DATA  BASE  RI .  IF  NO  MATCH,  SIDEROUTE  IS  CCMP.^EED 
TO  DATA  EASE  RI,  .^^-ND  IF  THESE  DO  NOT  .MATCH, 

DELIVERY  IS  TO  SVC.  (RxxxSCC  exception  to  DATA 
E.RSE  RI  ir.atchina  FL2  RI) 

S  =  SVC  DELIVERY  BASED  ON  SIDEROUTE  MATCH  TO  FL2  RI 
.A:ID  short  TITLE  RI  NOT  =  TO  FL2  RI 
V  =  '/DT  DISPLAY 


FIGURE-  4  ..f  .8-1.  Delivery  Decision  Table. 
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4 . 8. 3 


Non-Collectives .  - 


Over-the-Counter  (QTC).  If  the  delivery  is  one 
of  OTC,  the  short  title  is  either  a  "Protect"  or  "Guard"  short 
title.  Protect  short  titles  are  identified  by  a  "P" ,  "Q",  or 
"R"  in  the  data  base,  and  Guard  Command  short  titles  are 
identified  by  a  command  number  ranging  from  01-30. 


If  FL7/8  contains  FAS  office  codes,  a  FAS  line  is 
built  for  Guard  Commands,  but  not  for  Protects.  FAS  office 
codes,  if  present  are  located  between  double  slashs  (//).  The 
LDMX  will  save  this  information  in  the  form:  the  short  title 
identifier  followed  by  the  office  codes  (those  longer  than  three 
characters  are  truncated  to  three  characters),  each  of  which  is 
preceded  by  a  slash;  (i.e.,  ACPPTR/0P1/0P2/0P3 ) .  This 
information  is  used  in  distribution  processing. 


4. 8. 4  Collectives .  -  The  processing  of  these  short  titles 
faxls  into  four  categories:  RUCR  Processing,  Task  Processing, 
Type  Processing,  and  All  Others. 

RUCR  Processing.  When  FL2  contains  the 
collective  RI ,  "RUCRxxx" ,  and  the  short  title  is  a  collective 
short  title,  the  FL2-FL7/FL2-FL8  correlation  is  suppressed. 
Every  member  of  the  collective  will  get  delivery  except  for 
those  which  require  AUTODIN  delivery.  Full  period  and  dedicated 
deliveries  which  normally  are  set  during  FL2  processing  will  now 
be  set. 

TASK  Processing.  Those  short  titles  with  a 
naming  convention  (i.e.,  TFIO,  TGlO.l)  are  TASK  organizations, 
and  those  without  a  naming  conve.ntion  (i.e.,  Subrcn)  are  TYPE 
organizations.  A  distinction  is  made  between  the  two  during  the 
checksum,  algorithm  processing. 

TYPE  Processing.  These  kinds  of  collectives  are 
processed  ^ike  the  category  "All  Others"  except  where  their 
processing  would  have  stopped,  TYPE  processing  continues  with  a 
delivery  to  the  organization's  Comm.ander.  The  Commiander  is 
processed  as  a  single  non-siderouted  addee. 

All  Others.  This  processing  entails  delivery  to 
all  guarded  and  protect  commands  whose  RIs  appear  in  FL2. 

When  determining  "ACTION"  or  "INFO"  delivery 
requirem.ents ,  the  collective's  location  in  the  message  is  used. 
If  a  collective  appears  on  FL7,  the  collective  composition, 
which  also  contains  ACTION/INFO  indicators,  is  the  sole  source 
for  the  assignment.  Should  the  collective  appear  on  FL8,  all 
members  receive  the  messaae  as  info  addees. 
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"RxxxSCC"  RI  in  FL2  for  which  the  LDMX  is  required  to  protect, 
and  contains  a  siderouted  short  title  in  FL7  or  FL8  with  the 
same,  will  be  delivered  to  all  local  addees  (i.e.,  OTC)  without 
a  ZOV  pilotted  message  being  generated.  Non-local  RxxxSCC 
addees  will  be  ZOV'd  to  the  proper  station  automatically.  A 
copy  of  the  ZOV'd  message  will  be  delivered  to  a  service 
position.  (See  Automated  Misroute  Section). 


4.4. 8.6  '  ZOV  Message  Processing.  -  Once  a  FL7  or  FL8  has  been 
identified,  the  message,  if  a  ZOV,  is  delivered  to  all  of  the 
addees  which  were  contained  in  any  tare  lines.  Should  no  tare 
lines  exist,  and  the  number  of  RIs  in  FL2  is  equal  to  one,  then 
the  ZOV  message  will  be  delivered  to  the  addees  in  FL7  and/or 
FL8  which  have  matching  RIs  in  FL2.  If  the  message  contains 
more  than  one  RI ,  then  the  message  is  rejected  to  a  service 
position.  All  addees  whose  RI  does  not  appear  in  FL2  are 
rejected  to  a  service  position. 

4. 4. 8. 7  Readdressed  Message  Processing.  -  Upon  finding  a 
subsequent  FL5,  a  readdressal  format  is  presumed  and  no  further 
action  is  taken  on  format  lines  7,  8,  9,  or  10. 


4.x.  8. 8  T-ZI-JL  Processincr.  -  During  FL7/8  processing,  the  "T 
ZJ^T."  short  title  identifiers  previously  saved  during  FL4/FL4E 
validation  are  resolved.  The  "T  Z14L"  is  used  to  "ZEI'J"  miembers 
of  a  collective  in  which  case  delivery  by  electronic  means  is 
exempted . 


4. 4. 8. 8.1  Check  9 . 1 . a .  -  After  validation  of  the  From  Line 

the  heading  is  searched  for  FL7  and/or  FL8 . 

Error  Condition  -  The  prosicr.n  "TO"  or  "I'.'FO"  is 
not  contained  i.n  the  heading. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  F/L7  or  F/L8 
FOUND".  See  Message  Error  Processing  for  the  appropriate 
response . 


4. 4. 8. 8. 2  Check  9 . 1 . b .  -  A  search  is  made  to  find  the  short 

title  in  the  data  base. 

Error  Condition  -  The  short  title  is  not 
ccntai.ned  within  the  Data  Ease. 

Error  Resoluticn  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHORT  TITLE  NOT  IN 
DATA  B.^.SE"  .  See  .Message  Error  Processing  for  the  appropriate 


resDo.nse . 


contains  an  RI  followea  by  a  slash  (/),  five  spaces  and  a  short 
title . 

Error  Condition  -  The  short  title  line  contains 
an  RI  but  the  short  title  is  preceeded  with  five  spaces. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "RI/5  BLANKS  +  SHORT 
TITLE  FOUND".  See  Message  Error  Processing  for  the  appropriate 
response . 

4. 4. 8. 8. 4  Check  9 . 1 . d .  -  The  short  title  RI  retreived  is 
based  upon  the  message  classification  for  local  (OTC) 
deliveries . 

Error  Condition  -  The  short  title  RI  found  in  the 
data  base  is  not  cleared  to  receive  this  message. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  CLEIARED  RI/RI'S 
FOR  THIS  SHORT  TITLE".  See  Message  Error  Processing  for  the 
appropriate  response. 

4. 4. 8. 8. 5  Check  9 . 1 . e .  -  The  sideroute/short  title 
combination  contained  in  the  message  is  checked  for  proper 
association . 

Error  Condition  -  The  data  base  RI  does  not  agree 
with  the  siderouted  RI ;  or  sideroute  characteristics  (i.e., 
OTC,  FP,  etc.)  do  not  match  short  title  characteristics. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  a.n.notation  "  INCORRECT-SIEE  ROUTE 

aoprooriate  resco.nse. 


4.1 -8.8.6  Check  9 . 1 . f .  -  The  RI  indicates  a  local  delivery 

i§.“  required. 

Error  Condition  -  The  RI  is  a  local  RI  found  in 
the  Data  Base,  but  the  destination  is  invalid. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position'with  the  error  an.notaticn  "  I.NV.RLID  LRN  IN  DAT.R 
2A.SE  FOR  "  •  5g0  M0S53.cr0  2iriroir  F^rcc^ssin^  fot* 

appropriate  response. 


C  ^  g  £l  icr  *"  ^  .r.-2  sever, 

is  idertified,  and  the  message  is  a  MISROUTE  (ZOV). 

Error  Condition  -  The  message  contains  multiple 
RIs  in  FL2,  and  no  tare  instructions  exist. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  USE  OF  ZOV 
SIGNAL  -  MSG  SHOULD  CONTAIN  TARES”.  See  Message  Error 
Processing  for  the  appropriate  response. 


4 . i . a . 0 . 8  Check  9 . 1 . h .  -  The  short  title  is  a  guard  command 
and  the  Data  Base  entry  is  incorrect. 

Error  Condition  -  The  guard  command  number  for 
the  short  title  is  greater  than  the  maximum,  or  during 
processing  of  a  TASK  short  title  the  Data  Base  contained  an 
invalid  type . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "DATA  BASE  INCORRECT 
FOP.  lOIEX .  .  . XXX "  .  See  Message  Error  Processi.ng  for  the 
appropriate  response. 

4.  .8.8.9  Check  9 . 1 .  i .  -  The  Total  number  of  local  addees 
exceed  maximum  allowed  for  processing. 

Error  Condition  -  The  total  number  of  local  (OTC) 
addees  exceeds  500. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  pos^ition  with  the  error  annotation  "TOO  MANY  OTC  ADDEES 
TO  P.ROCESS".*  See  Message  Error  Processing  for  the  appropriate 
response . 


JATv'AP  Exem.ct  Address  Lines .  - 


4.  .9.1  Format  Line  9  (FL9)  Processing.  -  The  first  step  in 
FL9 ,  or  "XMT"  processing  as  it  is  referred  to  is  to  determ.ine  if 
the  prosign  "XMT"  exists  and  then  validate  the  short  title  to  be 
exempted.  This  is  accomplished  through  a  checksum  algorithm,  of 
the  short  title  and  then  determing  if  it  is  an  entry  in  the  Data 
Ease  . 

If  the  characteristics  of  the  aidee  being  exem.pt 
indicate  it  is  an  OTC  addressee,  then  the  addressee  m.ay  be 
either  a  guarded  or  a  protect  com.mand .  In  either  case,  delivery 
to  the  command  is  inhibited  and  processing  is  finished. 


identiiied,  the  short  title  following  the  prosign  and  all 
subsequent  short  titles  are  validated  for  the  correct  nunber  of 
characters . 

Error  Condtion  -  The  short  title  is  not  contained 
within  the  data  base. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHORT  TITLE  NOT  ON 
DATA  BASE".  See  Message  Error  Processing  for  the  appropriate 
response . 


4. 4. 9. 1.2  Check  10. 1 .b.  -  The  short  title  to  be  exempted  is 

not  a  single  addee  addressee. 

Error  Condition  -  A  collective  short  title  has 
been  detected  on  the  exempt  line. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "COLLECTIVE  SPECIFIED 
IN  XMT  LINE".  See  Message  Error  Processing  for  the  appropriate 
response . 


4. 1.9. 1.3  Check  10 . 1 . c .  -  The  subsequent  FL9  has  been  found 
but  the  short  title  does  not  follow  in  the  correct  position. 

Error  Condition  ~  The  short  title  is  indented  5 

or  more  spaces. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  F0RMA.T  LINE 
CONTINUATION".  See  Message  Error  Processing  for  the  appropriate 
response . 

4.4.9. 1.4  Check  10 . 1 ■ d .  -  The  short  title  to  be  exempted  is 
an  OTC  addressee. 

Error  Condition  -  The  guard  command  number  for 
the  short  title  is  greater  than  the  maxi.mum  allowed. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "DATA  EASE  INCOPJRECT 
FOR  I<ZXX.  .  .  See  Message  Error  Processing  for  the 

appropriate  response. 


4.  .10.1  Forr.at  Line  10  (FLIP)  Processing.  -  FLIP  15 

identified  by  the  prosign  "ACCT"  or  by  a  "GR"  followed  by  either 
"NC"  or  a  number.  Once  into  FLIP  processing,  the  accounting 
symbol  is  validated. 

Error  Condition  -  None. 

Error  Resolution  -  N/A 


4  ./  .  11 


JANAP  End  of  Header  Line. 


4.4.11.1  Format  Line  11  (FLU)  Processing.  -  Header  and 
heading  validation  is  concluded  when  the  first  "BT"  is 
identified.  The  first  "BT"  or  FLU  separates  the  heading  from 
the  classification  and  text  of  the  message.  If  a  valid  "BT"  is 
found,  message  validation  continues  with  FL12  processing.  If  an 
invalid  or  no  "BT"  condition  exist,  the  message  is  rejected  to  a 
service  position  for  the  appropriate  action. 


4.4-ll-l.l'‘  Check  1 2 . 1 .  a . 
indicating  FLU  . 


Check  for  the  prosign  "BT", 


Error  Condition  -  A  "BT"  has  been  found,  but  the 
message  has  no  FL7/a;  is  not  an  abbreviated  plaindress  message 
(CIC  contains  "ZYVW");  or  is  not  an  offline  encrypted  message. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  BT" .  See 
Hessaae  Error  Processing  for  the  aonrooriate  response. 


4.4.11.1.2  ’  Check  12.1.b .  - 
contained  on  FL2  are  accounted 


E.nsure  that  all  Local  ( OTC )  RI: 
f  or  . 


Error  Condition  -  FL2  contained  OTC  RIs  which  did 
not  match  any  short  title  in  the  message. 

Error  Resolutio.n  -  the  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  flATCH  FOUND  IN 
FL4/7/a  FOR  FL2  RI  -  P.xxxxxx".  See  Message  Error  Processing  for 
the  appropriate  respo.nse. 


4 .1 .  i: 


■.4I.'.^P  .Massacre  Classification  Line. 


.  4  12 .  .  "or  ^  .  r.e  .  71-11^  Troces^ino  .  -  i  ir.i' 
"BT”  or  FLU  La.  leen  identified  and  processed  without  error, 
format  line  12  (FL12)  is  the  next  line  searched  for.  FL12,  or 
the  classification  line  as  it  is  known,  contains  the  message 
classification  and  it  must  correlate  with  the  security  of  the 
message  identified  in  FL2 ,  FL4 ,  and  any  special  handling 
caveats.  If  the  message  is  "SPECAT" ,  FL12's  security  must  be 
CO.'JFIDEIJTIAL  or  above.  During  processing,  the  security 
.narrative  in  FL12  is  checked  against  a  classification  table  for 
a  match.  hny  discrepancy  results  in  the  message  being  rejected 
to  a  service  position. 

When  "SPECAT"  is  found  in  FL12,  the  message 
itself  must  have  the  appropriate  SPECAT  Release  Code  (SRC)  in 
FL4 .  If  it  does  not,  either  FL4  or  FL12  is  in  error  and  the 
message  is  rejected  to  a  service  position.  When  the  SRC  in  FL4 
contains  the  letter  "A",  then  the  caveat  following  "SPECAT"  in 
FL12  must  be  "SIOP-ESI".  All  other  SPECAT  caveats  are  valid 
when  the  SRC  "B"  is  contained  in  FL4 .  An  error  in  one  of  these 
conditions  will  result  in  the  message  being  rejected  to  a 
service  position. 

I'^en  "SVC"  is  found  in  FL12,  message  delivery  is 
set,  for  the  Servioe  Center. 

When  "NOFORN"  is  found  in  FL12,  it  indicates  that 
the  message  is  not  eligible  for  foreign  delivery.  If  a  foreign 
RI  has  already  been  identified  in  FL2  processing,  then  the 
.message-  i s  rejected  to  a  service  position. 

During  FL12  processing  a  search  is  made  for  a 
Navy  Standard  Subject  Identification  Code  (SSIC).  If  a  SSIC  if 
found  (i.e.,  //NOOOOO//)  and  further  validation  determines  that 
a  message  SSIC  is  indeed  in  the  line,  then  the  message  SSIC  is 
saved  for  subsequent  m.essage  distribution  processing. 

u.nique  feature  of  the  LDMX  is  that  it  allows 
each  site  to  handle  Special  Handling  Instructions  individually. 
I:  special  handling  is  identified  in  FL12,  the  message  will  be 
processed  lAW  the  special  instructions, 

.After  the  security  narrative  and  special 
indicators  in  FL12  have  been  processed,  a  search  of  FL12  is  m.ade 
for  sectional  i.nf ormation .  If  found,  the  current  section  number 
and  total  num.ber  of  seotions  information  associated  to  the 
m.essage  is  updated.  The  following  are  examples  of  valid  section 
i.nf  or.mat  ion  form.ats: 

(1)  Section  1  of  2 

(2)  Section  01  of  02 

(3)  Fi.nal  Section  of  2 

(4)  Final  Section  of  02 


?  3 


search  is  made  for  the  word  "SUBJ'.  "SUBJ"  is  used  as  to 
delimit  the  end  of  security  and  special  handling  information, 
and  to  identify  the  subject  line  of  the  message.  "SUBJ"  is 
required  to  be  used  as  a  delimiter  whether  or  not  a  subject  is 
given.  FL12  analysis  shall  persist  for  7  lines,  or  until 
recognition  of  other  lines  that  indicate  the  subject  line  has 
been  omitted.  A  reference  line  ( lef t- justif ied  "A.  ")  or  a 
paragraph  line  ( lef t- justif ied  "1.  ")  found  within  7  lines, 
before  finding  "SUBJ",  shall  be  considered  as  evidence  that  the 
"SUBJ"  line  does  not  exist.  In  such  cases  the  first  physical 
line  shall  constitute  the  bounds  of  security  and  special 
handling  information. 

For  DSSCS /GENSEIR  LD.MX  sites,  a  phrase  search  is 
performed  within  the  confines  of  the  "SUBJ"  line  or  the  first  7 
lines,  starting  with  FL12.  If  a  Phrase  is  detected  which  is 
associated  to  the  DSSCS  community  only,  then  an  error  condition 
exists  and  the  message  is  rejected  to  a  service  position. 

4.4.12.1.1  Check  13 . 1 . a .  -  The  security  narrative  is  checked 
against  the  message  security  classification. 

Error  Condition  -  The  FL12  classification  does 
not  match  FL2;  an  illegal  condition  exist  (i.e,,  special 
handling  instructions  in  a  SPECAT  message);  or  SPECAT  was 
i.ndicated  in  FL4  and  not  found  in  FL12. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SECURITY 
CLASSIFICATION".  See  Message  Error  Processing  for  the 
appropriate  response. 


4..f  .12.1.2  Check  1 3 . 1 .  b .  -  A  check  is  made  to  see  if  the 

message  is  eligible  for  foreign  delivery. 

Error  Conditicn  -  "NOFORN"  was  found  in  FL12,  and 
TRCs  are  present  in  FL4. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NOFORN  MSG  ROUTED  TO 
NON-US  RI".  See  Message  Error  Processing  for  the  appropriate 
response . 

4.4.12.1.3  Check  13.1.C.  -  If  a  DSSCS /GET.’SER  LDMX,  a  check 

is  made  for  possible  security  violations  between  com.munities . 

Error  Condition  -  A  DSSCS  phrase  has  been 
detected  in  a  GENSER  message  during  FL12  processi.ng. 

Error  Resolution  -  The  m.essage  is  rejected  to  a 
service  position  with  the  error  annotation  "SI-ONLY  PHR.^SE  FOUND 
IN  GEINSE.R  MSG".  See  Message  Error  Processing  for  the 
appropriate  response. 


■4.4.1 


4.4.13.1  Format  Lines  13/15/16  (FL13/15/16)  Processing.  - 

When  FL12  processing  is  complete,  the  remaining  message  body  is 
treated  as  message  text  until  the  second  "BT"  or  FL13  is  found. 
When  "BT"  is  found,  EOM  validation  occurs.  A  check  is  made  to 
determine  the  number  of  lines  remaining  in  the  message.  If  more 
than  2  lines  remain,  then  an  error  is  assumed  and  the  message  is 
rejected  to  a  service  position.  If  the  "BT"  appears  to  be  in 
the  proper  location,  then  FL15  is  validated.  FL15  begins  with 
the  sign,  and  if  it  is  not  present  an  error  is  assumed  and 

the  message  is  rejected  to  a  service  position.  If  the  sign 

is  present,  then  the  SSN  in  FL15  is  validated  to  be  numeric  and 
match  the  FL2  SSN.  Special  processing  is  invoked  for  FL15  if 
the  message  is  a  Switch  Converted  ACP  127  to  JANAP  128  message. 
After  FL15  validation,  the  last  line  in  the  message  is  the  4 
"N"s.  Once  again  if  the  exact  match  is  not  found  an  error  is 
assumed  and  the  message  is  rejected  to  a  service  position. 

After  EOM  validation  the  message  is  considered 
processed  and  placed  in  the  appropriate  transmission  queues 
"FIFO"  by  precednece  for  delivery. 


4.4.13.1.1  Check  14 . 1  .a .  -  Check  the  message  for  a  second 
"ET"  (EOM  indicator). 

Error  Condition  -  There  are  only  2  lines  of  data 
left  in  the  message  and  the  second  "BT"  has  not  been  found. 

Error  Resolution  -  The  m.essage  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  BT  F/L  13".  See 
Message  Error  Processing  for  the  appropriate  response. 

2  Check  14 . 1 . r .  -  Tne  second  “ET"  has  been  found 
.next  li.ne  m.ust  be  FL15,  provided  the  .message  L.MF  is  not 
",  "FA",  or  "L.“. '  . 

Error  Condition  -  The  "4^"  sign  is  missing  or  the 
4  digits  following  the  "  "  sign  are  not  numeric. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  positic.n  with  the  error  annotation  "INVALID  F/L  15". 
See  Message  Error  Processing  for  the  appropriate  response. 


4.. _.  13. 1.3  Check  14 . 1 .  c  .  -  FL15  is  present  and  the  last  li.ne 

must  contain  o.nly  the  characters  "NNNN". 

Error  Condition  -  The  line  following  FL15  does 
.not  contain  exactly  "NMNN". 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  F/L  16". 
See  Message  Error  Processi.ng  for  the  appropriate  response. 
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L^hX  Df\TA  PATTERN  tAESSAGE_PR0CE.5SING_RE(;)UlBEHtmS. 

L?  t:'  n  6r  4.  ci.  ^  w  J’  ni  ^  *  i  u  j  4  ~ 


4«{:l.l  This  section  will  detail  the  existing  LDMX  Data 
Pattern  format  processing. 

4<-ri.2  There  are  two  categories  of  data  pattern  formats 
processed  by  the  LDMX,  Incoming  Data  and  Outgoing  Data  Pattern. 
Within  the  two  categories  the  LDMX  processes  multiple  card  and 
single  card  data  pattern  messages. 


4»5, 2  Validation/Verification  Requirements.  - 

4*52.1  Format  Line  1  -  Transmission  Identifier  Line.  -  LDMX 

validation  of  the  TI  line  is  identical  for  both  asynchronous 
(Mode  II  and  V  teletypewriter  terminals  whose  use  of  a  TI  line 
is  mandatory)  and  synchronous  (Mode  I  users  who  employ  line 
block  framing  and  whose  use  of  a  TI  line  is  optional,  but  must 
be  specified  at  the  time  the  LDMX  sets  the  channel  parameters) 
channels.  All  TI  lines  through  the  CD-CSN  fields  are  processed 
as  follows: 

^'v2.1.1  The  first  characters  of  the  TI  line  bloc)c  must  be  a 

Start  of  Header  (SOH)  and  a  select  (SEL)  character.  If  the 
channel  is  asynchronous,  these  have  been  inserted  by  the  LDMX; 
if  the  channel  is  synchronous,  the  terminal  has  inserted  them. 


■^'^2.1.2  Checlt  1.1.  a.  -  The  first  data  character  of  the  TI 
line  must  be  the  letter  "C”.  (If  the  channel  is  asynchronous, 
the  "ZCZC"  portion  of  the  Start  of  Message  Sequence  (SOMS)  was 
previously  validated  and  then  discarded  by  the  LD.‘iX.  ) 

Error  Condition  -  None  -  nothing  can  be  recognized 
prior  to  receipt  of  the  SOH. 

Error  Resolution  -  N/ A 


^'^.2.1.3  Check  1 . 1 .  b .  -  The  second,  third  and  fourth 
characters  of  the  TI  line  must  be  the  Channel  Designator  (CD) 
and  must  match  the  CD  stored  at  the  LDMX  for  that  channel. 

Error  Condition  -  A  CD  is  considered  to  be  in  error  if 
it  does  not  match  the  CD  stored  in  the  LDMJ<  for  its  associated 
channel . 


Error  Resolution  -  Except  for  messages  of  ECP  or  Flash 
precedence,  messages  having  CD  errors  will  be  rejected  to  the 
service  position.  Precedence  categories  are  explained  later  in 
this  document. 


^ '?2 . 1  ,  A  Check  1  1  .  c.  -  The  fifth  chara.cter  erf  the  TI  l.r-; 
can  be  either  a  figures  shift  or  the  first  character  of  the  CSN 
field;  the  figures  shift  must  be  present  for  "A"  Select  ( ITA2 ) 
messages  and  may  or  may  not  be  present  for  other  selects.  Note 
that  for  all  processing  purposes,  "A"  Select  CSN's  are  always 
assumed  to  begin  in  the  sixth  position  of  the  TI  line.  This  is 
done  so  that  the  "CSN"  to  be  quoted  back  to  the  terminal  in  a 
service  message  will  be  positionally  correct  even  if  the  figure 
shift  is  garbled,  leaving  the  CSN  field  in  the  lower  case.  If 
the  CSN  is  correct,  TI  line  processing  is  complete  at  this 
point . 

Error  Condition  -  A  CSN  is  considered  to  be  in  error 
if  it  is  either  non-numeric  or  if  it  is  not  the  next  expected 
CSN  (i.e.,  one  greater  than  the  last  accepted  from  a  Mode  V 
cha.nnel  or  received  from  a  Mode  I  or  II  channel.)  For  this 
purpose,  a  CSN  of  000  is  considered  to  be  one  greater  than  999. 

Error  Resolution  -  Messages  of  ECP  or  Flash  precedence 
will  be  accepted  regardless  of  CSN  errors  detected.  Other 
messages  having  CSN  errors  will  be  processed  as  follows: 

If  the  CSN  is  a  duplicate  of  the  last  accepted 
(Mode  V)  or  received  (Mode  I/II),  the  message  will  be  rejected 
to  the  service  position.  This  is  the  only  instance  of  CSN  error 
where  a  message  will  be  rejected  by  the  LDMX  which  will  generate 
an  "OUT  OF  SEQUENCE"  message  to  the  input  channel  and  log  the 
error  condition  on  an  error  file  for  future  compilations 
(possibly  similar  to  the  existing  Com.munications  Improvement 
Memorandum  (CI.M)  program. 


If  the  CSN  is  incorrect  for  any  other  reason 
including  being  non-numeric,  the  message  will  be  accepted. 
However,  these  errors  shall  cause  the  LDMX  to  generate  a  service 
message  to  the  input  channel  citing  the  CD  and  CSN  as  well  as 
other  pertinent  message  identification  data.  This  service 


message  will  indicate  "POSSIBLE  DUFLIC.aTE"  ,  "OUT  OF  SEQUEIiCE" 


a.nd  whether  the  message 


will  cause  generation  of  an  open  num.ber  (ZFX)  service  message  to 


the  input  channel. 


-•52.1.5  Further  LDMX  TI  Line  Processing.  -  In  order  to 
maintain  CSN  continuity  between  the  LDMX  and  the  terminal,  the 
LDMX  tables  are  updated  based  on  the  results  of  CSN  a.nd  m.essage 
processing.  5-Jhen  a  CSN  is  rejected  (i.e.,  duplicate  condition), 
no  CSN  updati.ng  is  performed.  When  a  CSN  is  accepted,  even  if 
it  is  out  of  sequence,  the  accepted  CSN  (or  the  expected  CSN,  if 
the  received  CSN  is  non-numeric)  is  made  the  last  accepted  CSN 
for  processing  of  future  m.essages.  WTien  the  channel  is  Mode  I 
or  Mode  II  this  update  is  done  immediately  on  receipt  of  the  TI 
line  whether  the  associated  message  is  accepted  or  .not,  since 
the  Mode  I  or  Mode  II  terminal  is  assumed  to  update  the  CSN  at 
the  beginning  of  each  m.essage  transmission.  This  is  also 
consistent  with  a  termi.nal  transmitti.ng  a  tape  in  which  there 
are  pre-cut  CSN's  preceding  each  message.  Since  Mode  V 
procedures  require  that  CSN's  be  updated  on  acceptance  of  the 
message.  Mode  V  terminal  equipment  does  not  update  its  TI 


8  2 


generator  until  "the  associa,tea  it'eesajge  >101$  been  ackroule ag  e:2i  t'Y 
the  LDMI'l.  Consequently,  the  LEM2\  also  does  not  upaate  tne  last 
accepted  CSN  on  a  Mode  V  channel  until  the  message  has  been 
validated  and  accepted. 


4.53  Data  Pattern  Message  Format.  -  For  LDMX  Data  Pattern 

validation/verif ication  purposes,  the  format  is  divided  into 
five  parts:  Header  data  up  to  and  including  the 

Start-of -Routing  Sequence  (Format  Line  2);  the  Routing 
Indicator  Field  (still  a  part  of  Format  Line  2);  the  Security 
Line  (Format  Line  4);  Text  Data  (Format  Lines  5-12);  and  the 
E.nd  of  Message  (Format  Line  16). 

^'.3.1  Format  Line  2  Processing  Through  the  Start-of-Routina. 


4«V3.1.1  Precedence  Field.  -  The  first  header  field  to  be 
validated  is  the  precedence  field.  The  precedence  field  is 
processed  first.  Once  validated,  the  precedence  is  saved  for 
later  correlation  with  FL16  precedence ( s  )  . 

4.53.1.1.1  Check  2.1. a.  -  Precedence  is  a  single  character, 

the  first  character  of  the  header  and  is  validated  to  be  one  of 
five  characters: 

"Y"  -  Emergency  Command  Precedence  (ECP)  which  may 
be  input  only  on  authorized  channels. 

"Z"  -  Flash 

"0"  -  Immediate 

"P"  -  Priority 

"R"  -  Routine 

Error  Condition  -  If  the  field  is  .not  one  of  the  five 
precedence  characters  specified  above. 

Error  Resolution  -  An  error  in  the  precede.nce  field  of 
either  an  invalid  or  an  unauthorized  character  results  in  the 
message  being  rejected  to  a  service  position  witli  the  error 
annotation  "INVALID  PRECEDENCE".  See  Message  Error  Processing 
for  the  appropriate  response. 

^•^3.1.2  La.nauacre  Media  Format  (LMJ).  -  The  next  field  to  be 

validated  in  a  Data  Pattern  message  is  the  La.nguage  and  .Media 
Format  (L.MF)  field.  This  is  a  two  character  field  in  which  the 
first  character  (LMFl)  indicates  the  medium  in  which  the  input 
message  was  originally  prepared.  It  is  sometimes  also  called 
the  Input  L.MF.  The  second  character  ( L.MF2 )  indicates  the  medium, 
in  which  the  originator  prefers  the  message  to  be  delivered  to 
the  addressee.  It  is  som.etines  also  referred  to  as  the  Output 
LMF.  I.nput  header  processing  merely  validates  the  I.nput 
Media/ LfiF  combination.  Further  use  of  the  L.MF  in  input 
processing  and  in  output  messacje  delivery  will  be  discussed 


4:5  3 . 1 . -2  1  Cb-ecK  Q..2.a.  -  LtAF  va3  i'<ia.fion  is  a-lva^^  coo-baned 
with  the  validation  ol  the  Input  Media.  If  tne  message  is  iron 
a  TI  user,  the  SEL  is  obtained  from  the  second  framing  character 
of  the  TI  line  block.  Otherwise,  it  is  the  second  framing 
character  of  the  header  line  block.  Once  the  SEL-LMF 
combination  passes  validation,  the  LMF  pair  information  is  saved 
for  RI  processing,  which  must  determine,  whether  a  message  of  the 
specified  LMF  can  be  delivered  to  a  given  RI.  The  LMF  is  also 
compared  to  the  FL16  LMF  during  EOM  processing. 

Error  Condition  -  If  the  Input  Media/LMF  combination 
does  not  match  an  LDMX  table  entry,  the  Input  Media  is  validated 
separately . 

Error  Resolution  -  If  the  Input  Media  is  invalid,  an 
error  condition  is  logged  and  the  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  MESSAGE  TYPE 
CODE".  .See  Message  Error  Processing  for  the  appropriate 
response . 


J;'3.1.2.2  Check  2 . 2 . b .  -  The  message  is  identified  as  data 

pattern,  and  the  Input  LMF  or  Output  LMF'  must  specify  cards. 

Error  Condition  -  The  LMF'  does  not  conform  to  a 
valid  data  pattern  LMF. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  LMF”'.  See 
Message  Error  Processing  for  the  appropriate  response. 

4.53.1.3  Single  Security  Character  Field.  -  The  next  field  to 
be  validated  is  the  single  character  security  field.  Once 
validated,  the  security  character  is  saved  for  further  security 
c’necks  in  format  line  2,  4,  a.nd  16  processing.  The  single 

character  w'r.ich  indicates  the  security,  must  be  one  of  the 
following  characters: 

"T"  -  Top  Secret 

"S"  -  Secret 

"C"  -  Confidential 

"R"  -  Restricted 

"E"  -  Unclas  E  F  T  0  (encrypted  for  transmission 
only ) 

"U"  -  Unclassified 

4iH3. 1.3.1  Check  2 . 3 . a .  -  The  single  character  is  compared  to 

valid  security  characters  above. 

Error  Condition  -  Detection  of  an  invalid 
security  character. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position,  with  the  error  annotation  "INVALID 
CLASS-IFICATION"  .  See  Message  Error  Processing  for  the 
appropriate  response. 


4i53 . 3  4  Conlent  3r\<iicator  Co6e  CCIC  )  FielA,  -  The  four 
character  CIC  field  contains  iniormation  rexated  to  the  type  o: 
message  being  processed.  The  CIC  is  also  referred  to  as  the 
Communication  Action  Identifier  (CAI). 

■^1-3 . 1 . 4 . 1  Check  2 . 4  .  a .  -  The  CIC  is  validated  for  four 
alphabetic  characters,  or  three  alphabetic  and  one  numeric 
character . 

Error  Condition  -  Not  a  valid  CIC  or  not  enough 
characters  in  the  CIC. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  CIC".  See 
Message  Error  Processing  for  the  appropriate  response. 


'4.53.1.5 
a  space. 


Separator .  -  The  character  following  the  CIC  must  be 


3 . 1 . 5 . 1 
CIC  field. 


Check  2. 5. a.  -  Check  the  character  following  the 


Error  Condition  -  Any  character  other  than  a 


space . 


Error  Resolutio.n  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SEPARATORS 
IN  F/L  2".  See  Message  Error  Processing  for  the  appropriate 
response . 

5  3 . 1 . 6  Originating  Station  Routing  Indicator  (QSRI)  Field . 

-  Following  the  separator  is  the  seven  character  OSRI  field. 
Tnis  may  be  a  four  or  seven  character  Routing  Indicator  (RI> 
spaced  filled  to  seven  characters.  valid  OSRI  is  saved  for  a 
later  com.pariso.n  to  the  FL16  OSRI. 


-,1.3. 1.6.1  Check  2 . 6 .  a .  -  The  OSRI  is  validated  for  seven 
alphabetic  characters  or  at  least  four  alphabetic  characters 
with  the  remaining  positions  space  filled. 

Error  condition  -  The  OSRI  is  less  than  four  or 
greater  than  seven  characters,  or  contains  ncn-alphabetic 
characters . 


Error  Resolution  -  The  message  is  rejected  to  a 
service  positio.n  with  the  error  annotation  "INT/ALID  OSRI".  See 
Message  Error  Processing  for  the  appropriate  response. 


4 15  3 . 1 . 7  Oric^  {  na  t  i  no  Station  S  eri'al  Hurrber  (SSkj*)  Fl  el  d  ,  - 

Immediately  following  the  OSRl  is  the  SSh’  field.  The  SSN  i  • 
is  validated  for  four  numeric  characters.  L  valid  SSIJ  is  sav-_ 
for  later  comparison  with  the  Trailer  Station  Serial  Mummer 
(TSSN)  to  ensure  that  a  "straggler"  condition  does  not  exist. 
Straggler  checking  is  discussed  under  End-of -Message  validation. 

^,^3. 1.7.1  Check  2 . 7 . a .  -  The  SSN  field  is  validated  for  four 

numeric  characters. 

Error  Condition  -  The  SSN  is  not  numeric  or  four 
characters  in  length. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SSN".  See 
Message  Error  Processing  for  the  appropriate  response. 

4,53.1.8  Separator .  -  The  character  following  the  SSN  must  be 
a  space. 


4,53.1.8.1  Check  2 . B . a .  -  Check  the  character  followina  the 
SSN  field. 


space . 


Error  Condition  -  Any  character  other  than  a 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SEPARATORS 
IN  F/L  2".  See  Message  Error  Processing  for  the  appropriate 
response. 


4.53.1.9  Time-of-File  ?TjF)  Field.  -  The  TCF  field  is 
validated  for  seven  numeric  characters.  Procedural ly ,  the  TCF 
field  is  comiposed  of  a  three  digit  Julian  date  ( 001-3E5/366 )  a.nd 
four  digit  tim.e  (0000-2359)  a.nd  range  checks  are  m.ade . 


4i53. 1.9.1  Check  2 . 9 . a .  -  Check  the  TOF  field  for  seven 

.num.eric  characters  in  the  appropriate  ranges. 

Error  Condition  -  The  TOF  is  net  num.eric  or  seven 
characters  in  length. 

I 
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service  position  with  the  error  annotation  "I'.TlnLID  TOF".  See 
.Message  Error  Processing  for  the  appropriate  response. 


ID  ‘0 


’•^S.1.10  Separot.or . 

be  a  scace. 


Tbe  ch-aracter  ■roT.lcv/\n9  VVe.  TOr  r-ocV 


^'^3 . 1  .  10. 1 
TOF  field. 


Check  2 . 1 0 . a  .  -  Check  the  character  following  the 
Error  Condition  -  Any  character  other  than  a 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SEPARATORS 
IN  F/L  2".  See  .Message  Error  Processing  for  the  appropriate 

response . 

4,53.1.11  Record  Count  Field.  -  When  the  separator  is  a  blank 
character  this  field  is  checked  to  determine  if  the  message 

contains  a  pilot  (i.e.,  "PLTS"  or  an  ASC  NARC  "Rxxx"),  or  a 

valid  card  count  (i.e.,  ".MT.MS"  or  4  numeric  digits). 

4:5  3.1.11.1  Check  2 . 1 1 .  a .  -  Check  for  "PLTS"  (terminally 
ared)  or  "Rxxx"  (switch  prepared)  pilot  i.ndicators,  four 
rics  or  "MT.MS" 

Error  Condition  -  Record  cou.nt  field  contains 
data  other  tha.n  pilot  indicators,  or  a  valid  record  count. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  a.nnotation  "INVALID  RECORD  COUNT 
FIELD  FL/2".  See  Message  Error  Processing  for  the  appropriate 
r.esponse . 


Check 


owi.ncT  the 


^'5.3.1.33  Security  Redur dar c.y-Tt^C  Fields.  -  It>  -tKe.  Data 

Pattern  tor.nat,  the  four  character  Security  Redundancy  field  is 
validated  in  different  ways.  All  four  characters  of  the 

Security  Redundancy  field  must  be  identical  to  the  single 
security  character  previously  validated  (fourth  data  character 
of  the  header)  provided  the  message  is  not  addressed  to  an 
Allied  destination.  If  the  message  is  addressed  to  an  Allied 
destination,  the  last  two  characters  of  the  Security  Redundancy 
field  must  then  be  valid  transmission  release  codes  (TRCs). 
There  may  be  two  different  TRC  destinations  within  the  message 
and  both  RIs  must  be  in  Format  Line  2.  When  more  than  one  TRC 
is  indicated  they  have  to  be  arranged  in  alphabetical  order. 
Note  that  Format  Line  4  must  be  present  whenever  a  TRC 
indication  is  present  in  Format  Line  2.  The  classification 
redundancy  field  is  saved  to  compare  against  the  FL16 
classification  redundancy. 


1.13.1 


Check  2 . 13 . a .  -  Check  the  first  two  security 


characters  agai.nst  the  single  security  character  field. 


Error  Condition  -  The  first  two  characters  are 
not  identical  to  the  single  security  character  field. 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "CLASSIFICATION 
REDUNT.^CLCY  OR  TRC  ERROR".  See  Message  Error  Processing  for  the 
appropriate  response. 


^>^3.1.13.2  Check  2 . 1 3 . b .  -  The  last  two  characters  of  the 
Security  Redundancy  field  are  checked  to  see  if  they  are  valid 
TRCs,  or  security  characters. 

Error  Condition  -  The  two  characters  fail  the 
validation  check  (not  TRC  characters,  or  security  characters). 

Error  .Resolutio.n  -  The  message  is  rejected  to  a 
service  pcsition  with  the  error  annotation  "CLASSIFICATION 
REZ!UNT).“-NCY  OR  TRC  ERROR".  See  .Message  Error  Processing  for  the 
appropriate  response. 

^'53.1.14  Start  of  Routiner  (SOR)  Field.  -  .^fter  the  Security 
.Redu.nda.ncy  checks  are  complete,  the  SOR  field  is  then  validated. 
This  field  is  a  two  character  field  containing  dash  dash  (--). 


^•5  3.1.14.1  Check  2. 14.  a.  -  The  SOR  field  is  validated  for 
dash  dash  ( — ) . 


Error  Condition  -  The 
characters  other  than  a  double  dash  (--). 


SOR 


.eld  contains 


Error  Resolution  -  The  .message  is  rejected  to  a 
service  position  with  the  error  annotation  "I.N'VALID 
START-OF-ROUTING  SIGNAL".  See  .Message  Error  Processi.ng  for  the 
appropriate  response. 
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4.53.1 


Validation  of  the.  Fovjtir>^  Ind  i'C3tpr_  (M^  field. 


.3.2.1  Routing  Indicator  (RI)  Field.  -  The  RI  is  the 
"address"  of  a  message.  An  RI  may  not  be  split  by  either  spaces 
or  by  an  End  of  Line  (EOL)  sequence  in  any  instance.  The  RI  is 
examined  for  the  proper  form,  which  ranges  from  four  to  seven 
alphabet ic .characters .  A  separator  is  provided  between  each  RI 
unit.  Format  Line  2  may  contain  up  to  five  seven  character  RIs, 
eight  four  character  RIs,  or  any  combination  thereof,  not  to 


exceed  the 


character  line  length,  with  up  to  ten  RIs  on 


Format  Line  2  continuation  lines.  The  RIs  are  terminated  when 


the  End  of  Routing  sentinel  which  is  a  period  ( . )  is 
encountered.  During  RI  validation  the  RIs  are  examined  for  US 
and  Non-US  RIs.  It  is  the  RI  characteristics  found  that 
influence  to  what  extent  TRC  and  SHD  processing  is  performed. 


•4.53.2.1.1  Check  3.1.  a.  -  The  RI  must  contain  four  to  seven 

a  1 phabe  tic  cha  ra  c  t  e  r  s . 

Error  Condition  -  The  RI  contains  more  than  seven 
characters,  or  the  RI  contains  invalid  characters. 

Error  Resolution  -  The  m.essage  is  rejected  to  a 
service  position  with  the  error  a.nnotatio.n  "INV.ZiLID  ROUTING 
I.NDIC.^TOR " .  See  Message  Error  Processing  for  the  appropriate 
response . 


4,53.2.1.2 

AUTODIN. 


Check  3 . 1 . b  .  -  Is  the 


:ended  RI  destined  for 


Error  Condition  -  Either  a  CAR?  or  non-local  data 
patter.n  HI  received  from  .VJTCDIN,  the  message  contains  an 
invalid  RI ,  or  the  neszaae  ccr.tai.n  no  RIs. 

Error  Resolution  -  The  m.essage  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  VALID  RI  OR 
ILLEG/vL  RI".  See  Message  Error  Processing  for  the  appropriate 
response . 

4,3. 3. 2. 1.3  Check  3 . I . c .  -  An  Allied  Rcuting  Indicator  must  be 
accom.pai.ned  by  a  valid  TRC. 

Error  Condition  -  .A  valid  Allied  RI  is  found  and 
there  is  no  associated  TR.C. 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  TRC  FOR  M;’1I'<2''IXMX 
(MICC'C‘IXM=RI )  "  .  See  .Message  Error  Processing  for  the  appropriate 
resoonse . 


4.5  5  I. ‘4  Check  S.. -  CVieck  "the  rovjhir.c^  for  Scc.-US 
de  s  t;  mat.  i  om  . 

Error  Condition  -  The  message  is  single  card  and 
addressed  to  an  Allied  RI . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SINGLE  CARD  AND 
NON-US  RI  NOT  ALLOl-ED".  See  Message  Error  Processing  for  the 
appropriate  response. 

4153.2.1.5  Check  3 . 1 . e .  -  End  of  Routing  sentinel  has  not 
been  detected  and  the  RI  maximum  (500)  has  not  been  reached. 

Error  Condition  -  The  End  of  Routing  sentinel  has 
not  been  found  and  there  are  more  than  500  RIs  in  the  message. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "MORE  THAN  500  RI'S". 
See  Message  Error  Processing  for  the  appropriate  response. 

4.53.2.2  End-of -Routing  Field.  -  The  Data  Pattern  format 
End-of -Routing  (EOR)  consists  of  a  period  (.). 

'4;?.  3. 2. 2.1  Check  3. 2.  a.  -  ^’alidate  that  there  is  a  valid  EOR. 

Error  Condtio.n  -  The  last  field  in  Format  Line  2 
contains  an  invalid  EOR  sentinel. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID 
EL'ID-OF-ROUTING  SIGN.AL".  See  Message  Error  Processing  for  the 
appropriate  response. 

4 . V 3 . 3  Validation  of  the  Security  L ine .  - 


4,5. 3. 3.1  Security  Line  (FL4).  -  Following  the  EOR  processir-.u 

the  .next  field  to  be  validated  is  the  security  line,  format  line 
four.  If  a  pilot  header  is  present,  FL4  must  follow  the 
original  FL2.  For  all  messages  requiring  FL4 ,  the  first  four 
characters  following  the  EOR  must  be  the  operating  sig.nal  "2NR" 
or  "ZNY"  followed  by  a  space.  i-Jhen  it  is  determined  that  FL4  is 
present,  the  remai.ning  security  fields  are  processed.  Tne  first 
of  these  is  five  characters  in  length  and  m.ay  consist  of  five 
redunda.nt  security  characters,  or  three  redunda.nt  security 
characters  a.nd  two  transm.ission  release  cede  (TRC)  characters. 
Following  this  five  character  field  and  separated  by  a  slash 
'/),  may  be  from,  one  to  four  optional  special  handling 

designator  (SHD)  fields  (separated  by  a  slash)  or  a  SPECAT 
Release  Code  (SRC);  each  of  which  consists  of  a  five  character 
repetition  of  an  SHD  character.  There  may  be  only  one  set  of 
SRC  and  m.ay  not  be  m.ixed  with  messages  containing  TRCs  or  other 
SHDs.  Following  the  security  field,  separated  by  a  space,  m.ay 

9  0 


be  ope r'at \n3  Zx<^r.als,  vjhicb  3re  not  validated 


4i53.3.1.'5.  Check  4  .  I  .  a .  -  The  first  four  characters  of  FL4 

are  checked  to  see  if  they  contain  "ZNP,”  or  "ZNY"  and  a  space. 

Error  Condition  -  The  first  three  characters  are 
not  "ZNR"  or  "ZNY"  and  followed  by  a  space;  "ZNY"  and  a  space 
is  used,  but  the  FL2  security  redundancy  field  is  "UUUU";  or 
"ZNR"  and  a  space  is  used,  but  the  FL2  security  redundancy  field 
is  other  than' "UUUU". 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "CLASSIFICATION 

REDUNDANCY  OR  TRC  EiRROR".  See  Message  Error  Processing  for  the 
appropriate  response. 

^i53.3.1.Z  Check  4 . 1 . b .  -  The  first  three  characters  of  the 

security  field  are  validated  to  be  redu.nda.nt  a.nd  must  match  the 

security  redunda.ncy  field. 

Error  Condition  -  The  characters  are  not 
redundant  or  do  not  match  those  in  FL2 . 

Error  Resolutio.n  -  Tne  message  is  rejected  to  a 
service  positio.n  with  the  error  annotation  "CLASSIFIC.ATION 

0^  *^"^3  EPP*^P"*  S^0  M0SSacr^  Ejrt*oir  Piroc^ssincr  for'  ^**1^ 
appropriate  response. 


4.53  .3.1.3  Check  4 . 1 . c  .  -  The  next  two  characters  are  checked 
tor  security  redundancy  or  valid  TRCs. 


f  y“  ^  y”  ^  «*.  , 


fislf  ^00 
these  two 
characters 


_  security  redundancy 

s  r. of  infiotifs  Co  ,  3.^. f  ffi0  cri3r3Cw0rs  ir. 

r  edundant 


-cns  are  ether  tha.n  securitv 


Error  Resoluticn  -  The  m.essage  is  rejected  tc  a 
service  position  with  the  error  annotation  "CLASSIFIC.ATION 


RED'UND.ANCY  OP  T°C  E'^R'^R' 
incrccriate  resconse. 


See  .Messacre  Error 


>  m  I-  p 


i, 53. 3. 1.4 

redu.nda.ncy /TRC  field,  a  check  is  made  fc; 
Desiernater  (SHD)  senti.nel,  a  slash  (/),  or 


Check  4 . 1 . d .  -  After  validation  ci 

:he  i 


a  sca.'o 


c  o  ’  V"  •«  *•  •*» 


Error  Condi tic.n  -  .Any  character 


slash  (/),  a  space  or  a  valid  e.nd-of - 1  i.ne  sequence  follcwin-"^ 
previous  field. 
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Resolution  -  The  message  is  rejectee 


,o  a 


service  pcsitic.n  with  the  error  a.nnotaticn  "INVA.LID  SER.AR.ATOR 
CHARACTER  FL  4".  See  Message  Error  Processing  for  the 
appropriate  respc.nse. 
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4,53.3.1.^  Check  4  ■  1 .  e .  -  The  SHD/SfC  Sent-inel  is  found, 
check  the  classification  of  the  nessage  for  an  allowable  range. 

Error  Condition  -  The  classification  of  the 
message  is  below  CONFIDENTIAL . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SRC  NOT  ALLOWED". 
See  Message  Error  Processing  for  the  appropriate  response. 

^i?3.3.1.6  Check  4 . 1 . f .  -  The  message  classification  is 
acceptable,  check  for  a  valid  SHD/SRC  as  specified  in  ACP  117. 

Error  Condition  -  The  SHD/SRC  character  is  not  a 
valid  special  handling  category;  there  are  more  than  four  SHDs 
in  the  message;  the  SHD  is  repeated  more  than  once  in  the 
message,  or  there  is  more  than  one  SRC  in  the  message. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INV.ALID  OR  DUPLICATE 
SHD-FL4".  See  Message  Error  Processing  for  the  appropriate 
response . 


4,53.3.1.7  Check  4 . 1 .  cr.  -  The  message  classification  is 

acceptable  and  a  valid  SHJD/SP.C  exists,  check  the  five  SHD/SRC 
characters  to  ensure  they  are  redu.nda.nt . 

Error  Condition  -  A  valid  SHD/SRC  is  present  but 
the  5  character  group  are  not  redundant. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "IITJALID  SRC".  See 
Message  Error  Processing  for  the  appropriate  response. 


1:5^.  3.^  5  C''‘=ck  4.1.h  - 

the  input  cha.nnel/position  is  oh 
to  enter  SHD / SRC s. 


4-  V  o 

oCrISd  wO  30® 


Error  Condition  -  Special  handling  is  required 
for  the  m.essage  a.nd  the  input  channel /pcs  it  ion  is  not  authorized 
to  enter  the  SHD/SRC. 


s  e  r vi ce 

REQUIRED 

response 


Error  Resolutio.n  -  'Dl.e  m.essage  is  rejected  to  a 
position  with  the  error  annotation  "SPECI.^L  HA.NDLI.L'G 
See  Message,  Error  Processing  for  the  appropriate 


4<53,3,1,9  Che  cV,  A  .1. 1  ■  -  If  ^^^other  SHCj/SRC  sent  ir.el  i- 

f ound ,  the  next  rieid  is  validated  in  the  sane  manner  as  the 
first.  If  a  valid  SRC  is  detected  a  check  is  made  to  ensure 
there  are  no  transmission  release  code(s)  in  the  message. 

Error  Condition  -  The  message  contains  TRC ( s )  and 

a  SRC  in  FL4 . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SRC  NOT  ALLOWED". 
See  Message  Error  Processing  for  the  appropriate  response. 

4(53.3.1.10  Check  4.1.1.  -  The  FL2  security  redundnacy  field 
indicates  TRCs  required,  therefore  the  messacre  must  contain  a 
FL4. 

•  Error  Condition  -  TRCs  indicated  in  the  FL2 

security  redundancy  field  and  the  m.essage  contains  no  FL4 . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "MSG  WITH  TRC  BUT  NO 
FL  4".  See  Message  Error  Processing  for  the  appropriate 
response . 

4(53.4  '  Validation  of  TEXT  Data  Lines.  - 

4,53.4.1  TEXT  Lines  (FL5-12) .  Following  validation  of  FL4 , 
if  applicable,  all  remaining  lines  of  data  (80  character  record 
images)  are  treated  as  text  lines.  If  and  when  format  lines 
(i.e.,  FL5 ,  FL6 ,  etc.)  are  prese.nt  in  a  data  pattern  message  no 
validation  is  performed  on  them..  .4.t  this  point  all  m.essage 
lines  will  be  recorded  as  text  until  the  Trailer  card  (FL16)  is 
found.  The  following  exoeptions  apply  during  text  data 
processing . 

4,5  3 . 4 . 1 .  1  Check  5 . 1 .  a  .  -  Check  the  data  im.mediately 

following  the  header  card  (FL2). 

Error  Condition  -  The  Trailer  card  im.m.ediately 
follows  the  header  card. 

Error  Resolution  -  The  m.essage  is  rejected  to  a 
service  position  with  the  error  annotation  ".MESSAGE  HAS  NOT 
TEXT".  See  .Message  Error  Processing  for  the  appropriate 
response . 
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4,53.4.1^  ChecV^  5 . 1 ,  b  .  -  Taiiy  iVv'e.  toX  jL  ■cr  of  ire's::  9  j  e- 

1 ines . 
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Error  Condition  -  Tr^e  total  number  of  message 
lines  including  the  Header  and  Trailer  exceeds  500  lines. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "MORE  n-iAN  500 
MESSAGE  LINES".  See  Message  Error  Processing  for  the 
appropriate  response. 


4,53  .5  '  End  of  Message  (EO.M)  Line.  - 


-.3.5.1  Format  Line  (FL16)  Processing.  -  The  message  lines 
will  continue  to  be  processed  as  text  lines  until  the  maximum 
record  count  is  exceeded,  the  message  data  lines  are  depleted  or 
the  Trailer  card  is  ide.ntified.  Once  the  Trailer  card  (FL16)  is 
found  EOM  validation  will  be  performed. 

The  Header  and  Trailer  card  is  compared  against 
each  other  to  ensure  the  first  38  positions  of  each  record 
match.  Any  deviatio.n  is  considered  to  constitue  an  error. 

.4.fter  successful  validation  cf  FL16  the  data 
pattern  message  is  queued  for  deliver}’  to  the  card  punch  or  in 
some  cases  it  resides  in  a  Data  Pattern  Queue  until  the  message 
is  retrei'.’ed  a.nd  punched,  written  to  magnetic  tape,  cr  printed. 
.4ny  error  in  FL16  will  cause  the  message  to  be  rejected  to  the 
Service  Center  or  an  interactive  service  position. 


> ' 


4-53.5.1.1  Check  6 . 1 .  a .  -  Check  the  Header  precedence,  L.MF, 
and  security  red-cndanc3.’  field  against  the  Trailer  card. 


.M'TOEir.’ 
s  e  c  u  r  i  t 
match. 


Ccp.  — 

TAPE  ( LTME 
redu.ndancy  fields  i.n 


only 

the 


The  m.essame  is  incut 
and  the  orecede.nce,  LI-IF 
Header  and  Trailer  do 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  an.notation  "INT/.kLID  MESS.4GE 
TP.AIL5I?.".  See  Message  Error  Processi.ng  for  the  appropriate 
r espo.nse . 


Error  Condition  -  The  m.essage  is  an  outgoing  data 
pattern  messame  and  fne  precede.nce,  LMT,  and  security  redundancy 


Error 

service  position  w 
OP.  ILLEGAL  OUTGOING  ' 
appropriate  response 


Pesolut : on  -  The  message  is  rejected  to  a 
th  the  error  annotation  "NO  MESSAGE  TP-.kILEP 
’P".  See  Message  Error  Processing  for  the 
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4, 5. 3. 5. 1.2  Check  6.1.b.  -  Oeterr.ir.e  if  the  CSpa/SSM  an^ 
separator  fields  in  the  Header  card  natch  the  Trailer  card. 

Error  Condition  -  The  precedence,  LMF,  and 
security  redundancy  fields  match  but  the  OSRI/SSN  fields  do  not 
match,  and  the  message  does  not  have  a  pilot  header. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "  HEADER -TRA I  LE!R 
OSRI/SSN  MISMATCH".  See  Message  Error  Processing  for  the 
appropriate  response. 

Error  Condition  -  The  precedence,  LMJ',  and 
security  redundancy  field  match  but  the  OSRI/SSN  fields  do  not 
match,  and  the  message  has  a  pilot  header. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "PILOT  TRAILER 
OSRI/SSN  MISMATCH".  See  Message  Error  Processing  for  the 
appropriate  response. 

4i53.5.1.3  Check  6 . 1 . c .  -  The  record  count  is  checked  to 
ensure  proper  format  and  correct  line  count. 

Error  Condition  -  The  FL2  record  count  field  is 
not  "Jfl.MS",  all  numeric  data,  or  does  not  eaual  the  record  count 
in  FL16. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "RECORD  COUNT 
MISMATCH".  See  Message  Error  Processing  for  the  appropriate 
response . 


4.?3.5.1.4  Check  6 . 1 . d .  -  The  last  four  positions  of  the 
Trailer  card  (77-SO)  is  checked  for  the  EOM  i.ndicator. 

Error  Condition  -  Positions  77-80  in  the  Trailer 
card  contains  data  other  than  "NNN.N"  ,  and  the  message  was 
received  from  AUTODIN  or  TERM  TAPE. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "I'JVALID  MTISSAGE 
TRAILER".  See  Message  Error  Processi.ng  for  the  appropriate 
response . 

Error  Condition  -  Positions  77-80  in  the  Trailer 
card  contains  data  other  than  "NN.M'.’"  ,  a.nd  the  m.essage  was  an 
outgoing  data  pattern  message. 

Error  Resolution  -  Th.e  message  is  rejected  to  a 
service  position  with  the  error  a.nnotatio.n  "NO  MESS.^.GE  TR.^ILER 
OR  ILLEGAL  OUTGOING  TR "  .  See  Message  Error  Processi.ng  for  the 
appropriate  resoonse. 


5.0.  AGP  127  Format  Message  Processing  Requirements. 

5.1.  General  Comments. 

5.1.1.  This  section  details  the  existing  processing  as  it  applies 

to  ACP  127  message  formats  utilized  by  some  of  the  GENSER  community 
subscribers.  As  with  the  JAh'AP  128  message  processing 
requirements,  these  checks  and  validations  shall  be  performed  by 
the  I-SM  AMPE  in  such  a  manner  that  subscribers  are  provided  the 
same  service  on  an  interface  and  interaction  basis  that  they 
currently  derive  from  existing  ASCs  and  Service/Agency  AMPEs. 

5.2.  Validation/Ver if ication  Requirements 

5.2.1.  Format  Line  1  -  Transmission  Identifier  (TI)  Line.  I-S/A 
a;IPE  validation  of  the  TI  line  shall  be  identical  for  both 
asynchronous  (Mode  II  and  V  teletypewriter  terminals  whose  use  of  a 
TI  line  is  mandatory)  and  synchronous  (Mode  I  users  who  employ  line 
block  framing  and  whose  use  of  a  TI  line  is  mandatory  if  utilizing 
ACP  127  format  and  must  be  specified  at  the  time  the  I-S/A  AMPE 
sets  the  port/channel  parameters)  channels.  All  TI  lines  through 
the  CD-CSh  fields  shall  be  processed  as  follows: 

5. 2. 1.1.  The  first  characters  of  the  TI  line  block  must  be  a  Start 
of  Header  (SOH)  and  a  select  (SEL)  character.  If  the  channel  is 
asynchronous,  these  shall  have  been  inserted  by  the  I-S/A  AMPE;  if 
the  channel  is  synchronous,  the  terminal  has  inserted  them. 

5. 2. 1.2.  Check  1.1. a.  The  first  data  characters  of  the  TI 
line  must  be  a  valid  Start  of  Message  Sequence  (SOMS) 

Error  Condition  -  None  -  nothing  can  be  recognized 
prior  to  receipt  of  the  SOH. 

Error  Resolution  -  M/A 

5. 2. 1.3.  Check  1.1. b.  The  next  three  characters  of  the  TI 
line  must  be  the  Channel  Designator  (CD)  and  must  match  the  CD 
stored  at  the  I-S/A  AMPE  for  that  port  or  channel. 

Error  Condition  -  A  CD  shall  be  considered  to  be  in 
error  if  it  does  not  match  the  CD  stored  in  the  I-S/A  iV'lPE  for  its' 
associated  channel. 

Error  Resolution  -  Except  for  messages  of  ECP  or 
Flash  precedence,  messages  having  CD  errors  shall  be  rejected  to 
the  input  port  or  channel. 

5. 2. 1.4.  Check  l.l.c.  The  next  character  of  the  TI  line  can 
be  either  a  figures  shift  or  the  first  character  of  the  CSN  field; 
the  figures  shift  must  be  present  for  "A"  Select  (ITA  2)  messages 
and  may  or  may  not  be  present  for  other  selects.  If  the  CS'.'  is 
correct,  TI  line  validation  is  complete  at  this  point. 


Error  Condition  -  A  CSN’  shall  be  considered  to  be  in 
error  if  it  is  either  non-numeric  or  if  it  is  not  the  next  expected 
CSN;i.e.,  one  greater  than  the  last  "accepted"  from  a  Mode  V 
port/channel  or  "received"  from  a  Mode  I  or  II  port/channel.  For 
this  purpose,  a  CSM  of  000  shall  be  considered  to  be  one  greater 
than  999. 

Error  Resolution  -  Messages  of  ECP  or  Flash 
precedence  shall  be  accepted  regardless  of  CSN  errors  detected. 
Other  messages  having  CSN  errors  shall  be  processed  as  follows; 

If  the  CSN  is  a  duplicate  of  the  last  "accepted" 
(Mode  V)  or  received  (Mode  I/II),  the  message  shall  be  rejected  to 
the  input  port/channel.  This  is  the  only  instance  of  CSN  error 
where  a  message  will  be  rejected  by  the  1-S/A  AMPE  which  shall 
generate  an  "INVALID  CSN"  message  to  the  input  port  or  channel  and 
reecord  the  error  condition  for  future  compilations  such  as  the 
existing  Communications  Improvement  Memorandum  (CIM)  program.  If 
the  CSN  is  incorrect  for  any  other  reason  including  being 
non-numeric,  the  message  shall  be  accepted.  However,  these  errors 
shall  cause  the  I-S/A  AMPE  to  generate  a  service  message  to  the 
input  port/channel  citing  the  CD  and  CSN  as  well  as  other  pertinent 
message  identification  data.  This  service  message  shall  indicate 
"INVALID  CD",  "INVALID  CSN"  and  whether  the  message  was  accepted  or 
rejected.  A  duplicate  CSN  shall  cause  generation  of  an  additional 
service  message,  "DUPE  CSN".  When  a  CSN  is  received  out  of 
sequence,  an  open  number  (ZFX)  service  message  shall  be  generated 
to  the  input  port  or  channel  detailing  the  missing  CSNs. 

5. 2. 1.5.  Further  I-S/A  AMPE  TI  Line  processing.  To  maintain 

CS!.'  continuity  between  the  I-S/A  A)IPE  and  the  terminal,  the  I-S/A 
A^iPE  tables  shall  be  updated  based  on  the  results  of  CSN  and 
message  processing,  \vhen  a  CSN  is  rejected  (i.e.,  duplicate 
condition),  no  CSN  updating  shall  be  performed,  \vhen  a  CSN  is 
accepted,  even  if  it  is  out  of  sequence,  the  accepted  CSN  (or  the 
expected  CSN,  if  the  received  CSN  is  non-numeric.)  shall  be  made  the 
last  accepted  CSN  for  processing  of  future  messages.  NTien  the 
channel  is  Mode  I  or  Mode  II,  this  update  shall  be  done  immediately 
on  receipt  of  the  TI  line  whether  the  associated  message  is 
accepted  or  not,  since  the  Mode  I  or  Mode  II  terminal  is  assumed  to 
update  the  CSN  at  the  beginning  of  each  message  transmission.  This 
'is  also  consistent  with  a  terminal  transmitting  a  tape  in  which 
there  are  pre-cut  CSN's  preceding  each  message.  Since  Mode  V 
procedures  require  that  CSN's  be  updated  on  acceptance  of  the 
message.  Mode  V  terminal  equipment  does  not  update  its  TI  generator 
until  the  associated  message  has  been  acknowledged  by  the  I-S/A 
AMPE.  Consequently,  the  I-S/A  ^MPE  also  shall  not  update  the  last 
accepted  CSN  on  a  Mode  V  channel  until  the  message  has  been 
validated  and  accepted,  and  the  ACK  for  the  message  has  been  sent 
to  the  terminal. 
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5.3.  Format  Line  2  -  Message  Header.  For  I-S/A  AMPE  validation 
purposes ,  the  AC?  header  shall  be  divided  into  four  parts:  The 
precedence  field  including  the  start-of-rout ing  (SOR)  and  the 
optional  high-precedence  bell  signal  (FL2);  the  RI  field  (FL2);  the 
originating  subscriber  line  (FL3);  and  the  security  line  (FL4). 

5.3.1.  Precedence/Star t-of-Routing  Field.  The  first  step  in 
processing  an  AC?  format  header  shall  be  to  perform  a  search  for 
the  SOR.  In  AGP  format,  this  is  a  single  space,  normally  in  the 
third  data  position  following  the  repeated  precedence  prosign. 

5. 3. 1.1.  Check  2.1. a.  If  the  SOR  is  in  the  third  position,  the 
repeated  precedence  prosign  shall  be  validated.  The  five  valid 
prosigns  are: 

"YY"  -  Emergency  Command  Precedence  (ECP) 

"ZZ"  -  Flash 
"00"  -  Immediate 
"PP"  -  priority 
"RR"  -  Routine 

Error  Conditions: 

A  non-alphabetic  character  or  a  lower  case  ASCII  character  in 
either  position. 

Error  Resolution  -  The  message  shall  be  rejected  without 
exception  and  an  "IN'V'ALID  HEADER  -  REJ"  service  message  is 
automatically  generated  to  the  input  port  or  channel. 

Both  characters  are  alphabetic,  but  not  valid  precedence  characters 

Error  Resolution  -  The  message  shall  be  accepted  and 
processed  as  an  Immediate  precedence  ("00")  message. 

Only  one.  character  is  a  valid  precedence  character. 

Error  Resolution  -  The  message  shall  be  accepted  and 
processed  at  the  precedence  specified  by  the  one  valid  precedence 
character . 

Both  precedence  characters  are  valid,  but  unequal. 

Error  Resolution  -  The  message  shall  be  accepted  and 
processed  at  the  higher  precedence. 

Presence  of  a  ”Y"  in  either  position  of  a  message  from  a  port  or 
channel  not  authorized  ECP  input. 


Error  Resolution  -  The  message  shall  be  rejected  and  an 
"INVALID  USE  OF  ECP"  service  message  automatically  generated  to  the 
input  port  or  channel. 


Note:  In  the  above  cases  when  the  message  is  processed  as  one  or 

another  precedence,  the  precedence  prosign  shall  be  not  corrected 
but  shall  be  transmitted  to  an  ACP  format  subscriber  as  received. 

A  JANAP  subscriber  shall  receive  a  header  containing  the  precedence 
at  which  the  message  was  processed. 

5. 3. 1.2.  Check  2. 2. a.  If  the  SOR  is  not  properly  positioned,  a 
search  shall  be  made  to  determine  if  either  a  valid  or  garbled  bell 
signal  (SO/FIGS,  five  apostrophe  symbols,  five  bell  signals,  and  a 
SI/LTRS)  is  present.  The  determination  of  a  garbled  bell  signal 
shall  be  based  on  a  search  for  two  of  any  of  the  characters 
"apostrophe",  "bell",  "J",  or  "S".  Presence  of  either  a  valid  or 
garbled  bell  signal  shall  cause  the  message  to  be  handled  as  Flash 
unless  a  "Y"  is  found  in  either  precedence  character  and  the  port 
or  channel  is  classmarked  as  being  authorized  ECP  input. 

Error  Condition  -  Improperly  positioned  SOR. 

Error  Resolution  -  If  a  valid  or  garbled  bell  signal  is 
not  detected,  the  message  shall  be  rejected  and  an  "INVALID  HEADER 
-  REJ"  service  message  automatically  generated  to  the  input 
por t/channel . 

5.3.2.  Header  Validation  of  the  Routing  Indicator  Field.  The 
processing  of  an  ACP  format  RI  field  shall  be  essentially  the  same 
as  that  described  previously  for  the  JANAP  teletypewriter  format 
message  with  the  exception  of  the  EOR.  In  the  JANAP  format,  this 
sentinel  is  a  period.  In  the  ACP  format,  it  may  be  one  of  two 
letter  perfect  sequences:  Carriage  return,  carriage  return,  line 
feed  "D";  or  carriage  return,  carriage  return,  line  feed  "Z".  The 
"D”  indicates  the  start  of  FL3  whereas  the  "Z"  indicates  the 
presence  of  an  ACP  format  pilot. 

5. 3. 2.1.  Check  2. 3. a.  If  the  RI  field  contains  only  one  RI ,  a 
check  shall  be  made  for  a  valid  EOR  sequence.  If  the  RI  field 
contains  several  RIs  and  consists  of  more  than  one  line,  a  check 
shall  be  made  for  valid,  letter  perfect  end-of-line  sequences 
(CR,CR,LF)  terminating  each  line  and  a  valid  EOR. 

Error  Condition  -  Any  invalid  EOL  or  EOR  sequence. 

Error  Resolution  -  The  message  shall  be  rejected  and  an 
"INVALID  RI  FIELD"  service  message  is  automatically  generated  to 
the  input  port  or  channel. 

5.3.3.  Header  Validation  of  the  Originating  Station  Line  (DE 
Line/FL3) .  U'hen  the  EOR  is  found  as  CR,CR,LF"D",  the  program 
assumes  that  FL3  is  present.  See  Navy  JANA?  variations,  para 

4. 3. 3.1  for  FL3  validation  requirements.  '.>hen  the  EOR  is  found  as 
CR,CR,LF"Z",  the  I-S/A  AMPE  program  shall  assume  that  an  ACP  format 
pilot  precedes  the  original  header  and  the  "Z"  shall  be  assumed  to 
be  the  first  character  of  the  security  line  (FL4)  and  this  line 
shall  undergo  processing  prior  to  FL3.  A  separate  search  shall  be 
then  made  for  a  LF"D"  sequence  indicating  FL3  which  then  shall 
undergo  FL3  validation. 


5. 3. 3.1.  Check  3.1. a.  Once  an  EOR  is  validated  and  FL3  validation 
is  complete,  a  searcn  shall  be  made  for  the  next  line  feed  which 
indicates  termination  of  FL3.  This  line  feed  character  need  not  be 
part  of  a  perfect  EOLS ,  but  the  character  immediately  following  it 
must  be  the  beginning  of  FLA  which  is  indicated  by  the  letter  "Z". 

Error  Condition  -  Any  character  other  than  a  "Z" 
immediately  following  the  LF . 

Error  Resolution  -  The  message  shall  be  rejected  and  an 
"INT/ALID  SECURITY  FIELD"  service  message  automatically  generated  to 
the  input  port  or  channel  even  though  FLA  may  be  internally  correct. 

5. 3. 3. 2.  Check  3.1.b.  If  the  channel  is  not  classmarked  as  being 
exempt  from  straggler  detection  (as  are  some  Allied  channels),  the 
FL3  originating  station  serial  number  shall  be  located  and  stored 
for  later  comparison  with  the  serial  number  preceding  the  EOM 
function.  The  OSSN  field  immediately  follows  the  straggler 
sentinel  (A‘)  and,  unless  a  Cat  1  (ECP  or  Flash)  message,  must 
consist  of  four  numeric  characters. 

Error  Condition  -  The  message  is  not  a  Category  1  and 
contains  a  non-numeric  character  in  the  OSSN  field. 

Error  Resolution  -  The  message  shall  be  rejected  and  an 
"IN'V'ALID  HEADER"  service  message  automatically  generated  to  the 
input  port  or  channel. 

5. 3.  A.  Header  Validation  of  the  Security  Line  (FLA).  FLA, 
whether  part  of  a  pilot  or  a  normal  header,  shall  be  validated 
exactly  in  the  same  manner  as  described  for  teletypewriter  JANAP 
format.  The  only  significant  difference  in  processing  shall  be 
that  an  ACP  format  message  received  from  an  Allied  channel  must  not 
contain  a  TRC  and  all  five  security  characters  must  be  valid  and 
ident ical. 

5.3. A.I.  Check  A.l.a.  AC?  format  message  received  on  a  channel 
classmarked  as  Allied  must  contain  five  redundant  valid  security 
characters . 

Error  Condition  -  Use  of  a  TRC,  security  character  invalid 
or  not  repeated  five  times  on  an  ACP  formatted  message  received  on 
an  Allied  channel. 

Error  Resolution  -  The  message  is  rejected  and  an  "INT’ALID 
SECURITY  FIELD"  service  message  is  automatically  generated  to  the 
input  port  or  channel. 


5. A.  Routing  Indicator  Processing.  RI  processing  for  ACP 
format  shall  be  nearly  identical  to  that  for  JA.NAP  format.  RIs  in 
an  AC?  format  message  from  an  Allied  channel  shall  not  undergo 
validation  against  the  TRC  since  Allied  AC?  messages  cannot  use  a 


TRC.  Also,  since  there  is  no  LMF  field  to  specify  message  medium 


exchange  limitations,  an  ACP  format  message  shall  be  considered 


/  0  0 


V.-I.-  '.■>  :  ■t'  '.-v  ■.■V  ■.’•".V  V  "V'’  \  v’.  ’ r* 


-,r  V~,-V^ 


« 


deliverable  to  any  destination  that  is  compatible  on  the  basis  of 
community  and  security.  Message  exchange,  both  header  format  and 
medium,  shall  be  performed  as  necessary  on  output.  RIs  found 
invalid  for  any  reason  shall  be  included  in  a  service  message  sent 
to  the  input  port  or  channel.  All  system  generated  service 
messages  concerning  ACP  format  messages  shall  be  routed  to  a 
predetermined  R1  (service  message  RI  -  SMRI)  associated  with  the 
channel  of  receipt. 


5.5.  End-of  Message  (EOM)  Processing.  Upon  completion  of  SOMS 

validation,  a  continual  scan  of  each  message  for  the  end  of  message 
sequence  (EOMS)  shall  be  performed.  The  ACP  format  EOM 
procedurally  consists  of  two  carriage  returns,  eight  line  feeds, 
and  the  letters  "NNXM"  but  the  minimum  required  for  recognition  by 
the  I-S/A  AMPE  shall  be  one  line  feed  and  four  N"s.  This  scan  and 
others  that  shall  be  performed  for  the  detection  of  significant 
character  sequences  are  described  in  this  section. 

5.5.1.  Straggler  Protection.  A  "straggler”  is  caused  by  a 
message  without  a  valid  start  of  message  sequence  (SOMS)  following 
a  message  without  a  valid  end  of  message  sequence  (EOMS)  on  an 
asynchronous  channel,  or  two  messages  entered  as  one  on  a 
synchronous  channel  and  framed  SOH-ETX  as  a  single  message.  To 
protect  against  straggler  messages,  the  I-S/A  AMPE  shall  validate 
the  Originating  Station  Serial  Number  (OSSN)  in  the  message  header 
(FL3)  against  the  Trailer  Station  Serial  Number  (TSSN)  found  in  the 
message  trailer.  All  ACP  format  messages  are  not  subject  to  the 
straggler  validation  check.  If  the  straggler  sentinel  appears  in 
either  FL3  or  FL15,  straggler  validation  shall  be  performed  unless 
the  port  or  channel  is  specifically  classmarked  by  the  I-S/A  AMPE 
as  being  exempt  from  straggler  protection  checking. 

5. 5. 1.1.  Nith  ACP  formatted  messages,  the  OSSN'  Is  not  positioned 
absolute  (length  of  the  OSRI  is  variable)  and  a  straa->ler  sentinel 
(■■•)  is  employed  in  FL3  prior  to  the  four  or  acre  digit  OSSN.  The 
TSSN  must  also  be  preceded  by  a  straggler  sentinel  (■••)  which  must 
be  within  23  characters  of  the  End  of  Message  Sequence  (EOMS). 
Fields  of  over  four  characters  shall  be  acceptable  in  an  ACP  FL3 
and  in  the  trailer  but  only  the  four  characters  immediately 
following  the  sentinel  shall  be  used  by  the  I-S/A  A1!PE  for 
straggler  validation.  Failure  of  straggler  •'aliiation  shall  result 
in  message  rejection  unless  the  message  is  Flash  precedence,  and 
the  automatic  generation  of  a  "SUSPECTED  STR-AGOLER"  service  message 
to  the  input  port  or  channel.  Flash  messages  shall  be  accepted  and 
the  service  message  generated  shall  advise  the  input  port  or 
channel  "HIGH  PRECEDENCE  MESSAGE  ACCEPTED,  REPROTECT  SUSPECTED 
STRAGGLER" . 

5.5.2.  Cancel  Transmission  Sequence  (CAN'TR.ANS) .  The  I-S/A  .V'.PE 
shall  also  scan  for  the  presence  of  a  CjA.NTR.A.NS  which  procedurally 
consists  of  8  E's  each  separated  by  a  space,  the  letters  "AR" ,  and 
an  EOMS  of  two  carriage  returns,  eight  line  feeds,  and  four  N"s. 

The  minimum  recognizable  by  the  I-S/A  .AMPE  shall  be  two  E's 
separated  and  followed  by  a  space,  "AR",  one  linefeed,  and  four 

lO  1  ; 


N"s.  When  a  CANTRAN'S  is  recognized,  the  message  shall  be  discarded 
by  the  I-S/A  AMPE  with  notification  to  the  operator  that  the 
message  has  been  discarded. 

5.5.3.  Excessive  Message  Length.  An  additional  check  that  shall 
be  performed  during  receipt  of  message  text  is  a  count  of  total 
line  blocks  or  characters  being  received.  Should  this  count  exceed 
556  line  blocks  (A4,480  characters),  the  message  shall  be  rejected 
and  an  "EXCESSIVE  MESSAGE  LENGTH"  service  message  generated  to  the 
input  port  or  channel. 

5.5.4.  Excessive  Input  Hiatus.  Incoming  messages  shall  also  be 
monitored  for  any  delay  (hiatus)  in  receipt  by  the  I-S/A  AMPE. 

When  no  additional  data  is  received  for  a  non-CRITIC  message  in 
progress  for  a  period  of  approximately  three  minutes,  the  message 
shall  be  rejected  and  a  "NO  EOM  RECEIVED"  service  message  generated 
to  the  input  port  or  channel. 

5.5.5.  Framing  Character  (FC)  Processing.  Framing  characters 
shall  be  validated  for  all  input  messages.  On  asynchronous 
channels,  these  have  been  inserted  and  the  message  blocked  and 
framed  by  the  I-S/A  AMPE  itself  so  that  FC  validation  shall  be 
essentially  a  self-checking  process  by  the  I-S/A  AMPE.  On 
synchronous  channels,  FC  validation  shall  insure  proper  framing  by 
the  terminal  device.  Any  framing  character  error  shall  result  in 
message  rejection  with  a  "REPROTECT  TO  ALL  ADDEES"  service  message 
generated  to  the  input  port  or  channel.  In  addition,  notification 
of  the  FC  error  shall  be  provided  to  the  I-S/A  AMPE  operator  so 
that  any  FC  errors  caused  within  the  I-S/A  A-MPE  itself  may  be 
detected  and  corrective  action  taken. 
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6.1.1  This  section  will  detail  the  existing  MODIFIED  AGP  126 

format  processing. 


^.1.1.1  The  NAVY  originally  introduced  Modified  AGP  126 
message  format  into  the  telecommunications  network,  basically  to 
assist  the  Fleet.  However,  because  of  its  effectiveness,  the 
majority  of  Naval  message  originators  and  their  communications 
centers  prefer  this  format  as  it  provides/performs: 


1.  All  sectioning  and  paging. 


2  . 


classification, 
sideroutina . 


where  reauired. 


All  routing  based  upon  message 
short  titles  addressed,  and  existing 


3.  THG  assignment  and  multiple  transmassions 


4.  TARE  line  generation  based  upon  the 
reauirements  of  each  member  of  a  collective. 


5.  Sideroutina  where  aoDlicable. 


By  auto.T.acing  these  functions,  the  LDMX  has  reduced 
requirements  and  requires  stringent  checks  be  made 
titles  addressed.  Short  titles  are  the  key 
assignment  and  therefore  must  be  recognizable. 


its  manpower 
on  all  short 
to  routing 


Val idat icn/Ver if icaticr 


0.2.1  Format  Li.ne  1  -  Transmissio.n  Identifier  Line.  -  LD.'-'A 

validation  of  the  TI  line  is  ide.ntical  for  both  asynchronous 
(Mode  II  and  V  teletypewriter  terminals  whose  use  of  a  TI  line 
is  mandatory)  and  synchronous  (Mode  I  users  who  employ  line 
block  fram.ing  and  whose  use  of  a  TI  line  is  optional,  but  must 
be  specified  at  the  tim.e  the  LL.MM  sets  the  channel  parameters) 
channels.  All  TI  lines  through  the  GD-GSN  fields  are  processed 
as  follows: 


e 

®.2.1.1  The  first  characters  of  the  TI  line  block  miust  be  a 
Start  of  Header  (SOH)  and  a  select  (SEE)  character.  If  the 
cha.nnel  is  asynchronous,  these  have  been  inserted  by  the  LDMX; 
if  the  channel  is  synchronous,  the  terminal  has  inserted  them. 


6.2.  i.x  Check  -  The  ficsr  data  cha  ra  cte  r  of  AV\e  TTi 

line  must  be  the  letter  "C".  (If  the  channex  is  asynch: 
the  "ZCZC"  portion  of  the  Start  of  Message  Sequence  (SOMS) 
previously  validated  and  then  discarded  by  the  LDMX. ) 

Error  Condition  -  None  -  nothing  can  be  recognized 
prior  to  receipt  of  the  SOH. 

Error  Resolution  -  N/A 

^.2.1.3  Check  l.l.b.  -  The  second,  third  and  fourth 

characters  of  the  TI  line  must  be  the  Channel  Designator  (CD) 
and  must  match  the  CD  stored  at  the  LDMX  for  that  channel. 

Error  Condition  -  A  CD  is  considered  to  be  in  error  if 
it  does  not  match  the  CD  stored  in  the  LDMX  for  its  associated 
channel . 

Error  Resolution  -  Except  for  messages  of  ECP  or  Flash 
precedence,  messages  having  CD  errors  will  be  rejected  to  the 
service  position.  Precedence  categories  are  explained  later  in 
this  document. 

6.2. 1.4  Check  1 . 1 . c .  -  The  fifth  character  of  the  TI  line 

can  be  either  a  figures  shift  or  the  first  character  of  the  CSN 
field;  the  figures  shift  must  be  present  for  "A"  Select  ( ITA2 ) 
messages  and  may  or  may  not  be  present  for  other  selects.  Note 
that  for  all  processing  purposes,  "A"  Select  CSN's  are  always 
assumed  to  begin  in  the  sixth  position  of  the  TI  line.  This  is 
done  so  that  the  "CSN"  to  be  quoted  back  to  the  terminal  in  a 
service  message  will  be  positionally  correct  even  if  the  figure 
shift  is  garbled,  leaving  the  CSN  field  in  the  lower  case.  If 
the  CSN  is  correct,  TI  line  processing  is  complete  at  this 
poi.nt . 

Error  Condition  -  A  CSN  is  considered  to  be  in  error 
if  it  is  either  non-numeric  or  if  it  is  not  the  next  expected 
CSN  (i.e.,  c.ne  greater  than  the  last  accepted  from  a  .Mode  V 
channel  or  received  from  a  Mode  I  or  II  channel.)  For  this 
purpose,  a  CSN  of  000  is  considered  to  be  one  greater  than  999. 

Error  Resolution  -  Messages  of  ECP  or  Flash  precedence 
will  be  accepted  regardless  of  CSN  errors  detected.  Other 
messages  having  CSN  errors  will  be  processed  as  follows: 

If  the  CSN  is  a  duplicate  of  the  last  accepted 
(.Mode  V)  or  received  (Mode  I/II*),  the  message  will  be  rejected 
to  the  service  position.  This  is  the  only  instance  of  CSN  error 
where  a  message  will  be  rejected  by  the  LD.MX  which  will  generate 
an  "OUT  OF  SEQUENCE"  message  to  the  input  channel  and  log  the 
error  condition  on  an  error  file  for  future  compilations 
(possibly  similar  to  the  existi.ng  Com.m.unications  Improvement 
Memorandum  (CIM)  program. 


If  the  is  incorrect  for  nvcy  other  reasorv 
including  teing  non-nuneric,  the  message  will  be  accepted. 
However,  these  errors  shall  cause  the  LDMX  to  generate  a  service 
message  to  the  input  channel  citing  the  CD  and  CSTJ  as  well  as 
other  ■•■■ertinent  message  identification  data.  This  service 
message  will  indicate  "POSSIBLE  DUPLICATE",  "OUT  OF  SEQUENCE" 
and  whether  the  message  needs  to  be  protected  for.  Missing  CSNs 
will  cause  generation  of  an  open  number  (ZFX'  service  message  to 
the  input  channel. 


£.2.1.5  Further  LDMX  TI  Line  Processing.  -  In  order  to 
maintain  CSN  continuity  between  the  LDMX  and  the  terminal,  the 
LDMX  tables  are  updated  based  on  the  results  of  CSN  and  message 
processing.  When  a  CSN  is  rejected  (i.e.,  duplicate  condition), 
no  CSN  updating  is  performed.  i'Jhen  a  CSN  is  accepted,  even  if 
it  is  out  of  sequence,  the  accepted  CSN  (or  the  expected  CSN,  if 
the  received  CSN  is  non-numeric)  is  made  the  last  accepted  CSN 
for  processing  of  future  messages.  When  the  channel  is  Mode  I 
or  Mode  II  this  update  is  done  immediately  on  receipt  of  the  TI 
line  whether  the  associated  message  is  accepted  or  not,  since 
the  Mode  I  or  Mode  II  terminal  is  assumed  to  update  the  CSN  at 
the  beginni.ng  of  each  message  transmission.  This  is  also 
consistent  with  a  terminal  transmitting  a  tape  in  which  there 
are  pre-cut  CSN's  preceding  each  message.  Since  Mode  V 
procedures  require  that  CSN's  be  updated  on  acceptance  of  the 
message.  Mode  V  terminal  equipm.ent  does  not  update  its  TI 
ge.nerator  until  the  associated  message  has  been  acknow'ledged  by 
the  LDMX,  Consequently,  the  LDMX  also  does  not  update  the  last 
accepted  CSN  on  a  Mode  V  channel  until  the  message  has  been 
validated  and  accepted. 


V,  3  Messaq-e  Format.  -  For  NAVY  LDMK  validation/verif ication 
purposes,  the  .MODIFIED  ACP  126  form.at  is  divided  into  thirteen 
parts:  Header  data  up  to  a.nd  including  the  Start -of -Pout ing 
Seque.nce  (Format  Line  2);  the  Pcuti.nm  Indicator  Field  (still  a 
part  of  Format  Line  2);  the  Security  Line  (Fcrm.at  Li.ne  4 )  ; 
Passing  Instructions  (Form.at  Line  4  Extensio.ns )  ;  Operating 
Signals;  the  Date  Time  Group  (Form.at  Line  5);  the  Message 
Originator  (Format  Line  6);  the  Action/ Inf ormat ion  Addressees 
(Format  Line7/8);  the  Exempt  Addressee  (Format  Line  9);  the 
Accounti.ng  Symbol  (Form.at  Line  10);  the  .End  of  Header  (Format 
Line  11);  FL2,  FL4 ,  and  TARE  Line  generatio.n;  the  Message 
Classification  (Format  Line  12);  and  the  E.nd  of  Message  (Form.at 
Lines  13  throught  16). 
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Preced-enee  Field.  -_The  first  header  fie  id  to  he. 
validated  is  the  precedence  field.  Once  validatea,  the 
precedence  is  saved  for  later  correlation  with  FL5 
precedence ( s ) . 

£.3. 1.1.1  Check  2.1. a.  -  Precedence  is  a  single  character, 

the  first  character  of  the  header  and  is  validated  to  be  one  of 
five  characters: 

"Y"  -  Emergency  Command  Precedence  (ECP)  which  may 
be  input  only  on  authorized  channels. 

"2"  -  Flash 

"0"  -  Immediate 

"P"  -  Priority 

"P."  -  Routine 

Error  Condition  -  If  the  field  is  not  one  of  the  five 
precedence  characters  specified  above. 

Error  Resolution  -  An  error  in  the  precedence  field  of 
either  an  invalid  or  an  unauthorized  character  results  in  the 
message  being  rejected  to  a  service  position  with  the  error 
annotation  "INVALID  PRECEDEINCE" .  See  Message  Error  Processing 
for  the  appropriate  response. 

£.3.1.2  Language  Media  Format  (LMF).  -  The  next  field  to  be 

validated  in  a  MODIFIED  ACP  126  format  message  is  the  Language 
and  Media  Format  (LMF)  field.  This  is  a  two  character  field  in 
which  the  first  character  (LMFl)  indicates  the  medium  in  which 
the  input  message  was  originally  prepared.  It  is  sometimes  also 
called  the  Input  LMF.  The  second  character  ( LMF2 )  indicates  the 
medium  in  which  the  originator  prefers  the  message  to  be 
delivered  to  the  addressee.  It  is  sometimes  also  referred  to  as 
the  Output  LMF.  Input  header  processing  merely  validates  the 
Input  Media/ LME  combination.  Further  use  of  the  L.MF  in  input 
processing  and  in  output  message  delivery  will  be  discussed 
later . 


5-3. 1.2.1  Check  2. 2. a.  -  LMF  validation  is  always  combined 
with  the  validation  of  the  Input  Media.  If  the  message  is  from 
a  TI  user,  the  SEL  is  obtained  from  the  second  framing  character 
of  the  TI  line  block.  Otherwise,  it  is  the  second  framing 
character  of  the  header  line  block.  Once  the  SEL-LMF 
combination  passes  validation,  the  LMF  pair  information  is  saved 
for  RI  processing,  which  must  determine  whether  a  message  of  the 
specified  LMF  ca.n  be  delivered  to  a  given  RI . 

Error  Condition  -  If  the  Input  Media/LME  combination 
does  not  m.atch  an  LDMX  table  entry,  the  Input  Media  is  validated 
separately . 

Error  Resolution  -  If  the  Input  Media  is  invalid,  an 
error  condition  is  logged  and  the  message  is  rejected 
with  no  exceptions.  A  "REPROTECT  TO  ALL  .  ADDRESSEES"  service 
message  is  generated. 

\0(o 


When  the  TnpuT  a  is  valid,  but  one  ot  bbe  IJAF 

characters  is  invaiia,  specifically,  net  '"ri"'  or  "TC",  it  is 
rejected  to  a  service  position  with  an  "INVALID  LMF"  error 
annotation.  See  Message  Error  Processing  for  the  appropriate 
response . 


t.3.1.3  Sincrle  Security  Character  Field.  -  The  next  field  to 

e  validated  is  the  single  character  security  field.  Once 
validated,  the  security  character  is  saved  for  further  security 
checks  in  format  line  2,  4,  and  12  processing.  The  single 

character  which  indicates  the  security,  must  be  one  of  the 
following  characters: 

"T"  -  Top  Secret 
"S"  -  Secret 
"C"  -  Confidential 
"R"  -  Restricted 

"E"  -  Unclas  E  F  T  0  (encrypted  for  transmission 
only ) 

"U"  -  Unclassified 

■•^.3. 1.3.1  Check  2. 3. a.  -  The  single  character  is  compared  to 

valid  security  characters  above. 

Error  Condition  -  Detection  of  an  invalid 
security  character. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position,  with  the  error  annotation  "INVALID  SECURITY". 
See  Message  Error  Processing  for  the  appropriate  response. 


3. 3. 1.4  Content  Indicator  Code  (CIO  Field.  -  The  four 
character  CIC  field  contains  i.nf ermatien  related  to  the  type  of 
message  being  processed.  Ti-.e  CIC  is  also  referred  to  as  the 
Communication  Action  Identifier  ( CAI ) .  All  valid  CIC  values  are 
stored . 


g. 3. 1.4.1  Check  2. 4. a.  -  The  CIC  is  validated  for  four 
alphabetic  characters,  or  three  alphabetic  and  one  numeric 
character . 

Error  Condition  -  Not  a  valid  CIC,  one  listed  in 
LDfi>;  table,  or  not  enough  characters  in  the  CIC. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  positio.n  with  the  error  annotation  "INVALID  CIC  FORMAT”. 
See  M.essaae  Error  Processina  for  the  appropriate  response. 


ChecK.  'SL.  A.b.  -  T^e  CtC  \ridic3\es  3n  AD'^/^SC 
aenerared  pilot,  the  original  CIC  1  ro-n  r'oritat  Line  I  is  also 
validated  (dual  header  only). 

Error  Condition  -  No  valid  CIC  in  piloted  Format 
Line  2,  or  no  Format  Line  2  Extension  present. 


Error  Resolution 
service  position  with 

"INVALID  FORMAT  LINE  2".  See  Me 
appropriate  response. 

6.3. 1.4.3  Check  2.4.c.  -  The 
indicating  a  service  message. 

Error  Condition  - 
RI  validation  for  non  local 
format  validation  is  done. 

Error  Resolution 


The  message  is  rejected  to  a 
the  error  annotation 

sage  Error  Processing  for  the 


CIC  "ZYVW"  is  detected. 


None  -  Checks  are  made  during 
ris,  and  if  present  no  further 


N/A 


0.3. 1.5 
a  space. 


S. 3. 1.5.1 

CIC  field. 


space . 


Separator,  -  The  character 

following 

the  CIC 

must 

be 

Check  2. 5. a.  -  Check  the 

character 

f  ol Icwi 

.ng 

the 

Error  Condition  -  Any 

character 

other 

than 

a 

lervice 


Error  Resolution 
jcsitior.  with 


'  CHAR.'.CTER 


T’ER  Cl! 


-  The  message  is  rejected  to  <a 
the  error  annotation 

See  Messace  Error  Prccessincr  for 


riate  re: 


s  e 


3  .3.1.6  Orijinatinq  Station  Routi.ng  Indicator  (CSRI)  Field. 

-  Following  the  separator  is  the  seven  character  OSRI  field. 
This  .may  he  a  six  or  seve.n  character  Routing  Indicator  (RI) 
spaced  filled  to  seven  characters.  In  the  case  of  OCR  input, 
the  OSRI  field  may  be  blanks,  and  the  LD.MX  supplies  its  service 
service  center  RI  as  the  OSRI.  In  any  case,  a  new  OSRI  is 
generated  by  the  LDMX  for  Modified  ACP  126  formatted  messages  so 
that  subseque.nt  servici.ng  action  will  be  assum.ed  by  the  LD.MX. 
Both  the  original  and  generated  OSRI  are  saved  for  a  later 
comparison  to  determine  if  the  message  is  a  duplicate.  This  is 
discussed  i.n  detail  later  in  the  docum.ent. 


3.  1.6.1  Check  3..  6.  a  .  -  The  OSRI  does  not  begin  Vith 
"R”  ,  or  is  not  alphabetic  in  all  six  to  seven  positions,  and  not 
input  from  an  OCR. 

Error  condition  -  The  OSRI  begins  with  a 
character  other  than  "R"  or  contains  non-alphabetic  characters. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  OSRI".  See 
Message  Error  Processing  for  the  appropriate  response. 

6 . 3 . 1 . 7  Qricrinatincr  Station  Serial  Number  (SSN)  Field .  - 

Immediately  following  the  OSRI  is  the  SSN  field.  The  SSN  field 
is  validated  for  four  numeric  characters.  A  valid  SSN  is  saved 
for  later  comparison  with  the  Trailer  Station  Serial  Number 
(TSSN)  to  ensure  that  a  "straggler"  condition  does  not  exist. 
Straggler  checking  is  discussed  under  End-of -Message  validation. 
A  valid  SSN  is  used  along  with  the  OSRI  during  duplicate  message 
validation . 

Here  again,  the  LDMX  will  generate  an  SSN  based  upon  the 
original  message  OSRI  which  is  categorized  as;  Service  Center, 
Message  Center,  or  Data  Center. 

6. 3. 1.7.1  Check  2. 7. a.  -  The  SSN  field  is  validated  to  be 

four  numeric  characters. 

Error  Condition  -  The  SSN  is  not  numeric  or  four 
characters  in  length. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SSN".  See 
Message  Error  Processing  for  the  appropriate  response. 

^.3. 1.7. 2  Check  2.7.b.  -  The  SSN  is  compared  to  the  TSSN. 

Error  Condition  -  The  SSN  does  not  match  the  TSSN 
(Format  Line  15 )  . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 

"STRAGGLER  SSN  MISMATCH".  See  Message  Error  Processing  for  the 
appropriate  respo.nse. 

.S. 3.1.8  Separator .  The  character  following  the  SSN  must  be 

a  space. 


iOS 


SSN  field. 


ChecK  2l.  S.  a . 


CheciFv  -the  cKarac-^er  following 


space . 


Error  Condition  -  Any  character  other  than  a 


Error  Resolution 
service  position  with 

"INVALID  CHARACTER  AFTER  SSN". 
the  appropriate  response. 


-  The  message  is  rejected  to  a 
the  error  annotation 

See  Message  Error  Processing  for 


J.3.1.9  Time-of-File  (TQF)  Field.  -  The  TOF  field  is 
validated  for  seven  numeric  characters.  Procedurally ,  the  TOF 
field  is  composed  of  a  three  digit  Julian  date  (001-365/366)  and 
four  digit  time  (0000-2359).  Range  checks  are  made  provided  the 
message  was  not  input  from  an  OCR.  In  this  case  the  TOF  may  be 
all  zeroes  and  the  LDMX  will  assign  a  TOF  using  the  computer 
clock.  The  TOF  is  used  along  with  the  OSRI  and  SSN  in  duplicate 
message  validation,  which  will  be  discussed  later  in  the 
document . 


6  .3. 1.9.1  Check  2 . 9 . a .  -  Check  the  TOF  field  for  seven 

numeric  characters. 

Error  Conditio.n  -  The  TOF  is  not  numeric  or  seven 
characters  in  length. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  TOF".  See 
Message  Error  Processing  for  the  appropriate  response. 


6.3.1.10  Security 

the  TOF  field,  the 
uppercase  signall 

field.  If  the  Secur 
message  could  be  a  pil 
validated . 


Redundancy  Field  Secarator.  -  Followina 
cy:3.r3.Cw6r  rr.j3  w  cr  ( 1TA2 

i.ng  the  start  c:  the  Security  Redundancy 
ity  Redundancy  separator  is  misplaced,  the 
ot.  In  either  case  the  proper  fields  are 


3. 3. 1.10.1  Check  2 ■ 10 . a .  -  The  character  following  the  TOF 

is  not  a  dash  or  a  blank  character. 

Error  Condition  -  Any  character  other  than  a  dash 

or  a  blank. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 

"INVALID  SER.ARATOR  CHARACTER".  See  Message  Error  Processing  for 
the  appropriate  response. 


.€,3.1.11  Pj.lo.tecL  hessa^e  ? \  elA  ^  Vhen  t!h^  separator  is  a 
blank,  character  this  iieid  is  checKeu  to  aetermine  if  the 
message  contains  a  pilot  header.  All  pilot  lines  are  stripped 
and  the  original  FL2  is  used. 

6.3.1.11.1  Check  2 . 11 . a .  -  Check  for  "PLTS"  (terminally 
prepared)  or  "Rxxx"  (switch  prepared)  pilot  indicators. 

Error  Condition  -  Pilot  field  contains  data  other 
than  pilot  headers. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  PILOT/CARD  COUNT".  See  Message  Error  Processing  for 
the  appropriate  response. 

€.3.1.12  Record  Count  Field.  -  When  the  separator  is  a  blank 
character  and  does  not  contain  a  pilot  header,  this  field  is 
checked  for  valid  record  count  indicators. 

6.3.1.12.1  Check  2 . 12 . a .  -  Check  for  "MTMS"  or  for  four 
valid  numerics. 

Error  Condition  -  Record  Count  field  contains 
data  other  than  "MTMS"  or  four  numeric  characters. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  PILOT/CARD  COUNT".  See  Message  Error  Processing  for 
the  appropriate  response. 


3.3.1.13  Security  Redundancv/TRC  Fields.  -  In  the  MODIFIED 
ACP  126  format,  the  four  character  Security  Redundancy  field  is 
validated  in  different  ways.  All  four  characters  of  the 
Security  Redundancy  field  must  be  identical  to  the  single 
security  character  previously  validated  (fourth  data  character 
of  FL2 ) .  If  the  message  is  addressed  to  an  Allied  destination, 
the  last  two  characters  of  the  Security  Redundancy  field  will  be 
changed  to  reflect  valid  transmission  release  codes  once  all  PLA 
lookup  and  RI  generation  has  been  completed.  At  this  point 
however,  the  original  FL2  must  contain  four  identical  values 
which  match  the  fourth  data  character  of  FL2. 


6.3.1.13.1  (jheck  2 . 13  .  a  .  -  Check  the  four  security 

characters  against  the  single  security  character  field. 

Error  Condition  -  The  four  security  characters 
are  not  identical  to  the  single  security  character  field. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 

"SECURITY  REDUNDACY  ERROR  -  F/L  2".  See  Message  Error 
Processing  for  the  appropriate  response. 


g.3.1,H  Start  of  Rout  in<^  (SQR)  FielcA,  —  After  the  Security 
Redundancy  checks  are  coinplece,  the  SOR  field  is  then  validated. 
This  field  is  a  two  character  field  containing  dash  dash 

6.3.1.14.1  Check  2. 14. a.  -  The  SOR  field  is  validated  for 
dash  dash  ( -- )  . 

Error  Condition  -  The  SOR  field  contains 
characters  other  than  a  double  dash  (--). 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 
"INVALID  START  OF  ROUTING".  See  Message  Error  Processing  for 
the  appropriate  response. 


g.3.2  MODIFIED  ACP  126  Validation  of  the  RI  Field.  - 

6  .3.2.1  Routing  Indicator  (RI)  Field.  -  The  RI  is  the 
"address"  of  a  message.  An  RI  may  not  be  split  by  either  spaces 
or  by  an  End  of  Line  (EOL)  sequence  in  any  instance.  The  RI  is 
examined  for  the  proper  form,  which  begins  with  an  "R",  is  seven 
alphabetic  characters,  and  has  "SUU"  as  a  suffix.  Format  Line  2 
must  contain  only  the  one  RI  and  be  terminated  with  the  End  of 
Routing  delimiter. 

This  RI  field  is  what  determines  whether  the 
message  is  JAIJAP  128  or  Modified  ACP  126.  To  be  classified  as  a 
Modified  ACP  126  formatted  message,  there  must  be  only  one  RI 
whose  suffix  is  "SUU",  and  whose  NARC  equals  that  of  the 
processing  LDMX  or  one  which  the  processing  LDMX  has  accepted 
delivery  responsibility  for. 


3.  2 . 2 . 1 .  1  Check  2  .  1 .  a  .  -  The  first  character  of  the 

begin  with  a  "R" . 


a 


Error  Condtion  -  First  character  of  the  RI  is  not 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  a.nnotation  "INVALID  RI "  .  See 
Message  Er^or  Processing  for  the  appropriate  response. 


5. 3. 2. 1.2  Check  3 . 1 . b .  -  The  RI  must  contain  four  to  seven 
characters . 

Error  Condition  -  The  RI  contains  more  than  seven 
characters,  or  the  RI  contains  invalid  characters. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "IIJVALID  RI".  See 
Message  Error  Processing  for  the  appropriate  response. 


J6  3.2..3.  B:A-o-f_-_Rout -  TKe:  HODlFltD  kCP  IZfe  fort<v:^V 
r.na.-oi’ -Kou- mg  c:onb'i2t.a  oi  a  (.). 

6 . 3 . 2 . 2  .  If  Check  3. 2.  a.  -  Validate  that  there  is  a  valid  EOR. 

Error  Condtion  -  The  last  field  in  Format  Line  2 
contains  an  invalid  EOR  sentinel. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation 

"INVALID  END-OF-ROUTING  SIGNAL".  See  Message  Error  Processing 
for  the  appropriate  response. 


6.3.3 


MODIFIED  ACP  126  Validation  of  the  Security  Line.  - 


6 .3. 3.1  '  Security  Line  (FL4).  -  Following  the  EOR  or  original 
FL2  processing  the  next  field  to  he  validated  is  the  security 
li.ne,  format  line  four.  In  all  cases,  FL4  must  follow  the 
original  FL2.  The  first  four  characters  following  the  EOR  must 
be  the  operating  signal  "ZNR"  or  "ZNY"  followed  by  a  space. 
When  it  is  determined  that  FL4  is  present,  the  remaining 
security  fields  are  processed.  The  first  of  these  is  five 
characters  in  length  and  must  consist  of  five  redundant  security 
characters.  Following  this,  separated  by  a  slash  (/),  may  be 
from  one  to  four  optional  special  handling  designator  (SHD) 
fields  (separated  by  a  slash),  each  of  which  consists  of  a  five 
redundant  SHD  characters.  SPECAT  Release  Codes  (SRC)  are  the 
exception,  there  may  be  only  one  set  of  SRCs.  SRCs  and  SHDs  may 
not  both  be  contained  within  a  message.  Following  the  security 
field  or  SHD  characters,  separated  by  a  space,  may  be  operating 
signals  (Operating  signal  processing  is  discussed  later  in  the 
document)  or  oassina  instructions. 


.3. 3. 1.1  Check  5 . 1 . a .  -  The  first  four  characters  of  FL4 
are  checked  to  see  if  they  contain  "ZNR"  or  "ZNY"  and  a  space. 

Error  Condition  -  The  first  three  charac__ters  are 
not  "ZNR"  or  "ZNY"  and  followed  by  a  space;  "ZNY"  and  a  space 
is  used,  but  the  FL2  security  redundancy  field  is  "UUUU" ;  or 
"ZNR"  and  a  space  is  used,  but  the  FL2  security  re^fundancy  field 
is  other  than  "UUUU" . 


service 
4".  Se 


Error  Resolution  -  The  message  is  rejected  to  a 
ce  position  with  the  error  a.nnotation  "INVALID  FO.R.MAT  LINE 
See  Message  Error  Processi.ng  for  the  appropriate  response. 


ChecK.  5.1  .b .  -  The,  -^irsV  cWaracVerS  cf  4-We. 

security^  field  are  vaj-idated  be  reA.undant  and  musu  matcK  "the. 
security  redundancy  field. 


Error  Condition  -  The  characters  are  not 
redundant  or  do  not  match  those  in  FL2. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SECURITY  ON 
FORMAT  LINE  FOUR".  See  Message  Error  Processing  for  the 
appropriate  response. 


g.  3. 3. 1.3'  Check  S.l.c.  -  After  validation  of  the  security 
redundancy  field,  a  check  is  made  for  the  Special  Handling 
Designator  (SHD)  sentinel,  a  slash  (/),  or  a  space. 

Error  Condition  -  Any  character  other  than  a 
slash  (/),  a  space  or  a  valid  end-of-line  sequence  following  the 
previous  field. 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "ILLEGAL  CHARACTERS 
ON  FORMAT  LINE  FOUR".  See  Message  Error  Processing  for  the 
appropriate  response. 


6  .3. 3. 1.4  Check  S.l.d.  -  The  SHD  sentinel  is  found,  check 
the  next  five  characters  for  redundancy  and  they  must  be  valid 
SHD  category  characters  as  specified  in  ACP  117. 

Error  Condition  -  The  five  characters  are  not 
redundant,  not  a  valid  SHD  category,  SHDs  found  number  more  than 
four,  or  the  classification  of  the  messaae  is  below 
C0?3FIDENTI.^^L. 


Error  Resolutio.n  -  Tne  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  OR  DUPLICATE 
SHD  ON  F/L  4".  See  Message  Error  Processing  for  the  appropriate 
response . 


3. 3. 1.5  Check  5 . 1 . e .  -  If  the  SHD  sentinel  is  found,  the 
input  channel/position  is  checked  to  see  if  it  is  authorised  to 
enter  SHJDs . 


Error  Condition  -  Special  handling  is  required 
for  the  message  and  the  input  channel/position  is  not  authorized 
to  enter  the  SHD. 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SPECIAL  HANDLING 
REQUIRED".  See  Message  Error  Processing  for  the  appropriate 
response . 


£.3. 3. 1.6^  Ch e c K  5 . 1 , f  Xf  anc^V^er  SHO  ^ent'vrvei  C/^  \5) 

founa,  Lne  nexL  field  is  vaiiaatea  in  the  sarue  n^nner  as  tne 
first.  If  a  valid  SRC  is  detected,  a  check  is  made  to  ensure 
there  are  no  SHDs  in  the  message. 

Error  Condition  -  The  message  contains  an  invalid 
SRC,  or  the  SRC  does  not  agree  with  the  message  classification, 
or  SRC  is  present  with  other  SHDs. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SRC  ON 
FORMAT  LINE  FOUR"  or  "ILLEGAL  CLASS  WITH  SRC  OR  SHD" .  See 
Message  Error  Processing  for  the  appropriate  response. 

6. 3. 3. 1.7*  Check  S.l.g.  -  If  a  space  is  found  after  the 
security  redundancy  field  or  valid  SHD/SRC  fields,  additional 
operating  or  passing  instructions  may  be  present. 

Error  Condition  -  None  of  the  characters 
remaining  on  FL4  resemble  any  operating  signals  or  TARE 
instructions . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  TARE  LINE". 
See  Message  Error  Processing  for  the  appropriate  response. 

6.3.4  MODIFIED  ACP  126  Validation  of  FL4  Continuations.  - 

This  format  line  may  contain  only  operating  signals  or  "T  ZWL" 
tares  . 

5. 3. 4.1  Tare  Instruction  Search  (FL4/E) .  -  Tare 
instructions,  other  than  "T  ZkJL",  are  not  allowed  since  Modified 
AC?  126  formatted  messages  require  the  LDMM  to  supply  any 
required  T.^.RE  instructions.  Operating  signals  and  "T  ZWL" 
instructions  carry  through  onto  the  fully  formatted  LDMM 
generated  m.essage. 

6. 3. 4. 1.1  Check  6 . 1 . a  .  -  Check  for  valid  operating  sicnal  or 
"T  ZWL" . 

Error  Condition  -  The  message  contains  "T  ZWL" 
without  a  short  title. 

15;Error  Resolution  -  The  message  is  rejected  to 
a  service  po„^tio.n  with  the  error  a.nnotatio.n  "INVALID  TARE 
LINE".  See  Message  Error  Processing  for  the  appropriate 
response . 


,6.  3.  ^.1.3.  P^e^'iv  6_j.l_._b .  -  "if  a.  “T  2Wl"  is  found,  \\  sKcu\d.  be, 

followed  by  a  recognizaoie  srior-  title.  Z'lic  chert  tf _ 

identifier  will  be  saved  in  order  to  properly  process  format 
lines  7  and  8. 

Error  Condition  -  The  short  title  contained  on 
FL4/E  was  not  contained  in  the  LDMX  data  base. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHORT  TITLE  NO  IN 
DATA  BASE".  See  Message  Error  Processing  for  the  appropriate 
response . 

£.3.4.1.?  Check  S.l.c.  -  Ensure  all  "T  ZWL"  short  titles  are 
processed . 

Error  Condition  -  The  maximum  number  of  "T  ZWL" 
short  title  identifiers  is  reached. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "CAIJNOT  PROCESS  ALL 
'T  ZWL'.  MiAX  PER  MSG:  XX"  where  XX  represents  the  numerical 
maximum . 


8. 3. 4. 2  Operating  Signals  (Z-Sia.nal)  Processing.  -  Operating 
signals  or  Z-signals  as  they  are  called  may  be  found  on  format 
line  4,  format  line  4  extensions  or  format  line  5.  I4henever  a 
potential  Z-signal  is  detected,  control  is  passed  to  the 
appropriate  processing  module  for  validation.  Z-signal 
processing  is  discussed  in  three  parts:  Initial  "Z"  Signal 
Validation;  ZPW  Validation;  and  Other  "Z"  Signal  Validation. 

All  operating  signal  validations  are  passive,  to 
the  extent  that  just  because  a  word/ trigraph/etc .  m.ay  start 
with  a  "2"  it  does  not  mean  that  it  must  be  a  "Z"  signal  and  no 
errors  are  given  based  solely  on  a  "Z"  being  present. 

Initial  "Z"  Signal  Validaticn.  When  a  potential 
Z-signal  is  identified,  the  first  three  characters  of  the 
Z-signal  are  verified  for  alphabetics  and  the  fourth  character 
is  verified  to  be  either  numeric  or  blank. 


ZPW  Validation.  Whenever  the  Z-signal 
ide.ntified  the  remaining  data  is  verified  to  be  a 
numeric  Date-Tirae-Group  followed  by  the  letter  "Z". 


"ZPW"  is 
six  digit 


Other  "Z"  Signal  Validation 
"Z.N.M"  are  i.nvalid.  For  Z-signals  other 
sca.nned  for  the  corresponding  Z-signal 
appropriate  flag  is  set.  >7henever  the 


Z-signals  "ZXY"  and 
than  "ZPW"  a  table  is 
and  if  found  the 
Z-signals:  ZDK ,  2DG, 


ZFG,  ZFF4,  ZFF5,  ZFF6 ,  ZFril ,  ZFH2 ,  2FH3 ,  ZUI  , 


identified  the  message  is  directed  to  a  service  position  as  well 


as  the  primary  delivery  indicated  i.n  FL2  routing. 


U(o 


rj  'n 


* 


eg 


N.  ,  . 
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k,  -  - 

s 


g.'3).4,^.l  .ChecK  ,  b  ■  -  The  pctent-val  X-Si  gnal  is  Va  A  i<4.c%t-ecV 

lor  proper  forraat. 


Error  Condition  -  None  -  The  letter  "Z"  is  found 
in  a  line  however  it  does  not  match  an  'Z"  sional  in  the  LDMX 


table . 


Error  Resolution  -  N/A 


■€.  3 . 4 . 2 . 2  Check  6 . 2  . b  .  -  The  Z-sianal  is  one  of  "ZPW". 


Error  Condition  -  The  "ZPW"  Z-signal  is 
identified  and  the  Date-Time-Group  field  contains  invalid 
characters,  or  the  line  does  not  end  with  a  "2". 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "BAD  ZPW  TIKE".  See 
Message  Error  Processing  for  the  appropriate  response. 


6.  3 . 4 . 2 . 3  Check  6 . 2 . c .  -  The  Z-signal  field  contains  the 

characters  "ZNM". 


Error  Condition  -  The  "ZNK"  Z-signal  is  not 
permitted  in  the  message. 


Error  .Pesclut  1  c.n  -  The  .message  is  rejected  to  a 
service  position  with  the  error  annotation  "ZN.M  ILLEGAL".  See 
Message  Error  Processing  for  the  appropriate  response. 


6. 3. 4. 2. 4  Check  6.2.d.  -  The  Z-signal  field  contains  the 

characters  "ZXY". 


Error  Condi sicn  -  _.'-.e  "LEY"  Z-signal  is  detected 
nl  requires  deliver*.’  he  rru oe  os  she  addr e s s e  indicated  hv  the 


cursh  character  of  the  Z-sicr.nal. 


mrror  .^esclusic.n  -  The  message  is  rejected  to 


ser’/ice  position  with  the  error  annotation  "ZXY  SIGNAL  FOUND". 
See  .Message  Error  Processi.ng  for  the  appropriate  response. 


5.  3 . 4 . 2 . 5  Check  6.2. e.  -  A  Z-signal  is  detected  without 
for.mat  errors,  but  does  .not  .’satch  a  specific  Z-sig.nal  requiring 
addition  action. 


V-  n  V" 


..one 


ihe 


itcnal  IS 


•/alidated  for  crener  format  a.nd  stored  as  a  cart  of  the  messaae. 


6.3.5 


MOP'F^EO  ftCP  1^6  Va  I  >  ip^  cf_  Date-Time-Grov^p  Lip^. 

'£.3.5.1  Date-Time-Group  (FL5).  -  Following  validation  of 
format  line  four  extensions'  (tare  instructions  and  operating 
signals),  the  next  line  validated  is  the  Date-Time-Group.  The 
Date-Time-Group  consists  of  the  Precedence  field(s),  the  actual 
day,  hour,  and  minutes  of  the  message,  a  terminator,  the  month 
field,  and  a  year  field.  Format  line  5  may  also  contain 
operating  signal(s)  if  the  message  warrants  them.  Operating 
signal  processing  has  been  previously  discussed  in  this 
document . 


VALID  FORMAT  LINE  5  STRUCTURE: 


P  DDHHMM2  MON  YR 
PI  DDHRMMZ  MON  YP 
P  I  DDHHMMZ  MON  YP  , 

LEGEND : 

P  =  ACTION  PRECEDENCE 
I  =  INFO  PRECEDENCE 
DD  =  VALID  DAY  -  RANGE  01  THRU  31 
HH  =  VALID  HOUR  -  RANGE  00  THRU  23 
MM  =  V.ALID  MINUTE  -  RANGE  00  THRU  59 
Z  =  ZULU  TIME  DESIGNATOR 
MON  =  VALID  MONTH 
YR  =  NUMERICAL  YEAR 

Each  of  the  aforementioned  structures  may  contain 
operating  signals  and  the  "YR"  must  always  be  present. 


S.  3 . 5 . 1 . 1  Check  7 . 1 .  a .  -  Check  the  first  character  of  the 

DTG  for  a  valid  precede.nce. 

Error  Condition  -  There  is  only  one  precedence  in 
format  line  5  and  it  does  not  equal  the  FL2  precedence. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  a.n.notatio.n  "PRECEDENCE  ERROR  ON 
F/L  5".  See  Message  Error  Processing  for  the  appropriate 
response . 


S.3.5.1.2  Check  7.1.b.  -  Validate  the  second  position  of  the 

DTG  for  a  space  or  valid  INFO  precedence. 


Error  Condition  -  An  illegal  INFO  precedence 
character  follows  the  action  precedence  character;  or  a 
character  other  than  a  space  follows  the  second  precedence 
character  of  the  DTG  field. 


I  •  "  »  •  •  "  •  ■  c 

•  •  •  ^ 


Error  Kesokutiori  -  TV>e.  vTess0.ge.  js  re^eeiecX  ±0  3. 
service  positicn  with  the  error  annotation  "NO  BLANK  AFTEK 
PRECEDENCE  FIELD  ON  F/L  5".  See  Message  Error  Processing  for 
the  appropriate  response. 

6. 3. 5. 1.3  Check  7 . 1 . c .  -  The  third  position  in  the  DTG  is 
validated  for  a  dual  precedence  or  the  beginning  of  the 
Date-Time-Group  field. 

Error  Condition  -  If  the  third  character  is  not 
an  alphabetic  precedence  character  less  than  the  first 
precedence  in  FL5 ,  a  numeric  character  indicating  the  first 
character  of  the  Date-Time-Group,  or  a  space  and  the  FL5 
structure  is  "PI  ". 

\  Error  Resolution  -  The  message  is  rejected  to  a 
service  j position  with  the  error  annotation  "INVALID  DTG  ON  F/L 
5".  See 'Message  Error  Processing  for  the  appropriate  response- 

6.3.5.1.4  Check  7 . 1 . d .  -  Ranae  checks  are  performed  on  the 
DTG  field. 

Error  Condition  -  The  six  characters  following 
the  precedence  field  and  that  start  in  the  correct  position  are 
not  numeric;  the  day  portion  is  zero  or  greater  than  31;  the 
hour  portion  is  greater  than  23;  or  the  minute  portion  is 
greater  than  59. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  DTG".  See 
Message  Error  Processing  for  the  appropriate  response. 

6.  3 . 5 . 1 . 5  Check  7.1.8.  -  The  DTG  digits  are  valid  numerics 
with  the  specified  range  and  ends  with  a  "2". 

Error  Condition  -  Tne  Date-Time-Group  field  ends 
with  a  character  other  than  a  "2". 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  Z  FOR  ZULU  ON  F/L 
5".  See  Message  Error  Processing  for  the  appropriate  response. 

S. 3. 5. 1.6  Check  7 . 1 . f .  -  A  valid  separator  must  follow  the 
Date-Time-Group. 

Error  Condtion  -  The  character  following  the  "Z" 
field  of  the  DTG  is  not  a  space. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  BLANK  AFTER  DTG 
FIELD  ON  F/L  5".  See  Message  Error  Processing  for  the 
appropriate  response. 


VV'l 


6. 3. S.  1,7  -  Checl<L_7  !.  Lv.g  •  “  TV>€.  tronth  fteld  -foli  ow  mg  t-W 
separator  is  valiaated  for  tne  appropriate  content. 

Error  Condition  -  The  characters  identified  in 
the  month  field  of  FL5  do  not  match  any  of  the  valid  twelve 
months . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  MONTH  ON  F/L 
5".  See  Message  Error  Processing  for  the  appropriate  response. 


g. 3. 5. 1.8  Check  7 . 1 .h.  -  If  the  month  field  is  valid  it  must 

be  followed  by  a  valid  separator. 

Error  Condition  -  The  character  following  the 
month  field  is  not  a  space. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  BLANK  AFTER  MONTH 
ON  F/L  5".  See  Message  Error  Processing  for  the  appropriate 
response . 

^.3, 5. 1,9  Check  7 . 1 . i .  -  All  messages  require  the  year  field 

to  be  present  in  FL5, 

Error  Condition  -  The  message  did  not  enter  the 
system  from  AUTODIN  and  does  not  contain  a  year  in  FL5 . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "YEAR  MISSING  ON  THIS 
F/L  5",  See  Message  Error  Processing  for  the  appropriate 
response . 

2.3.5.1.10  Check  7.1.1.  -  If  the  year  field  contains  data  it 

is  checked  for  a  valid  year. 

Error  Condition  -  The  year  field  contains  data 
and  it  is  not  numeric  data. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  '"'s'E.AR  IS  NOT  NUMERIC 
ON  F/L  5".  See  Message  Error  Processing  for  the  appropriate 
response . 

£.3.6  .MODIFIED  ACP  126  Validation  of  Originator  (FL6)  Lines. 


•  From  Line  (FLfo)  -  The  Or  (<3  ina-tcr's  Shor-t  1"! ‘tie- 
referred  to  as  FL6  ,  -is  -verified  to  •  ensure  ""it -is  wi-thin  rhe 
correct  character  limits;  and  that  it  exists  in  the  Data  Base. 
For  local  LDMX  processing  there  are  two  types  of  short  titles: 
a  Protect  Short  Title  and  a  Guard  Command  Short  Title,  In 
either  case,  the  LDMX  performs  special  message  distribution  and 
backrouting  dependent  upon  whether  a  Protect  or  Guard  Short 
Title  is  found. 


B. 3. 6. 1,1  Check  8.1. a.  -  A  search  is  made  to  find  the  short 

title  in  the  data  base. 

Error  Condition  -  The  short  title  is  not 
contained  within  the  Data  Base. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHORT  TITLE  NOT  IN 
DATA  BASE".  See  Message  Error  Processing  for  the  appropriate 
response . 


0.3.7  MODIFIED  ACP  126  Validation  of  ACTION/ INFO  Lines.  - 

"0.3.  7.1  Format  Line  7  8  (FL7/8)  Processing.  -  The 

processing  of  FL7/8  requires  that  the  short  title  first  be 
isolated.  To  do  this,  it  is  determined  if  the  short  title  is 
siderouted  and  whether  it  is  processing  a  format  line  containing 
the  prosign  "TO"  or  "INFO".  When  the  prosign  is  present,  it  is 
skipped  and  validation  starts  with  the  sideroute  search. 
Sideroutes  consist  of  ris,  ZEN,  ZEINl ,  or  ZEN2  followed  by  a 
slash  (/),  Should  the  line  contain  "ZEN"  in  any  of  the 
aforementioned  formats,  no  Short  Title  validation  is  done. 

Format  Line  seven  or  eight  may  contain  a  si.ngle 
sideroute  or  dual  sideroutes.  In  order  to  be  classified  as  a  RI 
sideroute,  it  must  begin  with  the  character  "R",  be  between  four 
and  seven  alphabetic  characters  in  length,  and  end  with  a  slash 
(/).  Once  the  RI(s)  have  been  identified  they  are  saved  for 
later  processing  and  the  short  title  has  now  been  isolated  for 
processing. 

The  isolated  short  title  can  now  be  used  to 

access  the  data  base.  From,  the  data  base  and  the  message 
classification,  it  can  be  determined  if  the  short  title  will  be 

"cleared".  It  also  provides  FL7/8  processing  with  the  proper  RI 

assignment  and  TARE  line  requirem.ents .  This  RI  is  used  to 

sideroute  the  short  title,  if  it  is  not  already  siderouted,  and 
saved  for  building  a  "new”  FL2.  The  creating  of  a  "new"  FL2  is 
discussed  later  in  this  document. 

In 'addition,  short  titles  identified  as  being 
"alternate  spellings",  (derivatives  of  a  "preferred"  spelling) 
will  be  replaced  by  their  "preferred  spelling".  "Alternate 
spellings"  were  created  in  order  to  reduce  m.anual  intervention 
rates  (MIRs)  by  allowing  abbreviations,  and  frequent  misspelling 
of  a  short  title  to  be ,  recognizable  to  the  autom.ated  systems. 

'.7.\ 


6. 3. 7. 3 


Non-Collectives. 


Over- the-Counter  (PTC).  If  the  delivery  is  one 
of  OTC,  the  short  title  is  either  a  "Protect"  or  "Guard"  short 
title.  Protect  short  titles  are  identified  by  a  "P" ,  "Q",  or 
"R"  in  the  data  base,  and  Guard  Command  short  titles  are 
identified  by  a  command  number  ranging  from  01-30.  All 
pertinent  data  is  saved  for  distribution  processing. 

If  FL7/8  contains  FAS  office  codes,  a  FAS  line  is 
built  for  Guard  Commands,  but  not  for  Protects.  FAS  office 
codes,  if  present  are  located  between  double  slashs  (//).  The 
LDMX  will  save  this  information  in  the  form:  the  short  title 
identifier  followed  by  the  office  codes  (those  longer  than  three 
characters  are  truncated  to  three  characters),  each  of  which  is 
preceded  by  a  slash;  (i.e.,  ACPPTR/0P1/0P2/0P3 ) .  This 
information  is  used  in  distribution  processing. 

Non-Local  (NON-OTC).  No  special  processing 

required. 


6-3. 7. 4  Collectives .  -  Collectives  are  totally  expanded  to 
identify  all  members.  Each  member  is  looked  at  separately  to 
determine  RI  assignment,  proper  clearances,  and  TARE  line 
generation  requirements.  Each  RI ,  in  turn,  is  saved  for  the 
creation  of  a  new  FL2.  Collective  processing  is  basically  not 
much  different  from  non-collectives  except  processing  requires 
the  involvement  of  multiple  member  short  titles  vice  one. 

When  determining  "ACTION"  or  "INFO"  delivery 
requirements,  the  collective's  location  in  the  message  is  used. 
If  a  collective  appears  on  FL7 ,  the  collective  ccmpositio.n , 
which  also  contains  .ACTION/INFO  indicators,  is  the  sole  source 
for  the  assignment.  Should  the  collective  appear  on  FLS,  all 
members  receive  the  message  as  info  addees. 


6  .3.7.5  Readdressed  Message  Processing.  -  Upon  finding  a 
subsequent  FL5,  a  readdressal  format  is  presumed  and  no  further 
action  is  taken  on  format  lines  7,  8,  9,  or  10. 


®.3.7.6  T-ZWT.  Processing.  -  During  FL7/S  processi.ng  the  "T 
ZWL"  short  title  identifiers  previously  saved  during  FL4/FL4E 
validation,  are  resolved.  The  "T  ZWL"  is  used  to  "ZEIN"  members 


of  a  collective  in  which  case  delivery  by  electronic  means,  is 
e.xempted . 


L 


g.3.7.S.i  CheOC  9  .  i .  a.  -  After  v  9  I  j  Ast  i  o  ri  "t  he  prom  L+rve. 

the  heaaing  is  searched  for  FL7  and/or  FL6. 

Error  Condition  -  The  prosign  "TO"  or  "INFO"  is 
not  contained  in  the  heading. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  F/L7  or  F/L8 
FOUND".  See  Message  Error  Processing  for  the  appropriate 
response . 

€.3. 7. 6. 2  Check  9 . 1 . b .  -  A  search  is  made  to  find  the  short 

title  in  the  data  base. 

Error  Condition  -  The  short  title  is  not 
contained  in  the  Data  Base. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHOP.T  TITLE  NOT  IN 
DATA  EASE".  See  Message  Error  Processing  for  the  appropriate 
response . 

6.3. 7.6.3  Check  9 . 1 . c .  -  Format  Line  7  or  Format  Line  8 

contains  an  RI  followed  by  a  slash  (/),  five  spaces  and  a  short 
title . 

Error  Condition  -  The  short  title  line  contains 
an  RI  but  the  short  title  is  proceeded  with  five  spaces. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "RI/5  BLANKS  +  SHORT 
TITLE  FOUNT)".  See  Message  Error  Processing  for  the  appropriate 
response . 


j.3. 7.6.4  Check  9.1.d.  -  The  short  title  RI  retreived  is 

based  upon  the  message  classification  for  all  addees. 

Error  Condition  -  The  short  title  RI  found  in  the 
data  base  is  not  cleared  to  receive  this  message. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  CLEARED  RI/RI'S 
FOR  THIS  SHORT  TITLE".  See  Message  Error  Processing  for  the 
appropriate  response. 


■3.  3 . 7 . 6 . 5  Check  9 . 1 .  e  .  -  The  sideroute/ short  title 
combination  contained  i.n  the  message  is  checked  for  proper 
association . 

Error  Condition  -  The  data  base  RI  does  not  agree 
with  the  sidercuted  .RI;  or  sideroute  characteristics  (i.e., 
OTC,  FP,  etc.)  do  not  match  short  title  characteristics. 


sideroute/ short 


title 


grTcr  Rescl  ut~Jor\  -  The  iressa3e  is  rejected  tc  9 
service  position  with  the  error  annotation  "INCORRECT-SIDE  ROUTE 
FOR  XXXX . . . XXX ” .  See  Message  Error  Processing  for  the 
appropriate  response. 

6.3. 7.6.6  Check  9 . 1 . f .  -  The  RI  indicates  a  local  delivery 
is  required. 

Error  Condition  -  The  RI  is  a  local  RI  found  in 
the  Data  Base,  but  the  destination  is  invalid. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  LRN  IN  DATA 
BASE  FOR  XXXXXXX" .  See  Message  Error  Processing  for  the 
appropriate  response. 


3.  3. 7.6. 7  Check  9 . 1 . g .  -  The  short  title  is  a  guard  command 

and  the  Data  Base  entry  is  incorrect. 


Error  Condition  -  Tl.e  guard  command  number  for 
the  short  title  is  greater  than  the  maximu.m,  or  during 
processing  of  a  TASK  short  title  the  Data  Ease  contained  an 
invalid  type. 

Error  Resolutic.n  -  Tne  message  is  rejected  to  a 
service  position  with  the  error  annotatio.n  "ROUTFL  INCORRECT  FOR 
>C'IXX .  .  . XI'C< " .  See  Message  Error  Processing  for  the  appropriate 
response . 

6. 3. 7. 6. 8  Check  9 . 1 . h.  -  The  Total  number  of  local  addees 
exceed  maximum  allowed  for  processing. 

Error  Condition  -  Tr.e  total  number  of  local  (CTO 
addees  exceeds  500. 

Error  Resolution  -  Tr.e  .message  is  rejected  to  a 
service  position  with  the  error  a.nnooation  'TOO  .MANY  CTC  .ADDEES 
TO  PROCESS".  See  Message  Error  Processing  for  the  appropriate 
response . 


0.3. 7. 6. 9  Check  9 . 1 .  i  .  -  Total  number  of  .RIs  generated  must 

remain  within  the  maximum. 


Error  Condition 
ce.nerated  exceeded  500. 


The  ootal  num.ber  of  .RIs 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "MORE  TH.AN  500  P.Is". 
See  Message  Error  Processing  for  the  appropriate  response. 


6.3.7vfa.j0  ChecVk  *9 .  \ —  Wh-en  s.jc\erouVA03 

the  coiubined  length  of  the  sideroute,  short  title,  and  FAS  or 
office  codes  must  not  exceed  maximum  line  lenath. 


Error  Condition  -  The  line  length 
during  sideroute  insertion. 


exceeded 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "LINE  TOO  LONG,  EINTER 
P.  OR  X.".  See  Message  Error  Processing  for  the  appropriate 
response . 


t.  3 . 8 


MODIFIED  AGP  126  Exemot  Address  Lines.  - 


£.3.8.1  Format  Line  9  (FL9)  Processing.  -  The  first  step  in 
FL9 ,  or  "XMT"  processing  as  it  is  referred  to  is  to  determine  if 
the  prosign  "XMT"  exists  and  then  validate  the  short  title  to  be 
exempted.  This  is  accomplished  through  a  checksum  algorithm  of 
the  short  title  and  then  determing  if  it  is  an  entry  in  the  Data 
Base . 

If  the  characteristics  of  the  addee  being  exempt 
indicate  it  is  an  OTC  addressee,  then  the  addressee  may  be 
either  a  guarded  or  a  protect  command.  In  either  case,  delivery 
to  the  command  is  inhibited  and  regardless  of  the  short  titles 's 
characteristics  (i.e.,  OTC,  Non-  Local,  etc.),  RI(s)  generated 
during  FL7/S  processing,  are  eliminated.  The  short  title's 
RI(s)  must  be  removed  so  that  they  will  not  be  present  in  the 
"new"  FL2  that  is  to  be  built.  The  creation  of  the  "new"  FL2  is 
discussed  later  in  this  document. 

A  special  search  is  done  through  the  FL7/8 
generated  RIs  to  detect  w’hether  a  accounting  symbol  (FLIO)  is 
required  in  the  m.essage.  This  is  done  by  scanning  for  a 
ccmm.ercial  refile  HI. 


ccmm.ercial  re: 


sca.nnina 


5.  3.  d.  1.1  Check  10 . 1 .  a .  -  .After  the  prosign  "X.MT"  has  been 
identified,  the  short  title  following  the  prosign  and  that  all 
subsequent  short  titles  are  contained  within  the  data  base. 


Error  Condtion  -  The  short 
7ithin  the  data  base. 


;le  is  not  contained 


Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "SHORT  TITLE  NOT  IN 
D.AT.A  EASE".  See  Message  Error  Processing  for  the  appropriate 
response. 


rr-' 

L-  -’ ' 


,V' 


t;: 


K.. 


t:: 


6  3.S.1.2?"  CKec K  lO.  i  , b .  —  The  short  title  to  fa's  e^cempteA  i-5 
not  a  single  addee  addressee. 

Error  Condition  -  A  collective  short  title  has 
been  detected  on  the  exempt  line. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "COLLECTIVE  SPECIFIED 
IN  XMT  LINE".  See  Message  Error  Processing  for  the  appropriate 
response . 

£.3. 8. 1.3  Check  1 0 . 1 . c .  -  The  subsequent  FL9  has  been  found 

but  the  short  title  does  not  follow  in  the  correct  position. 

Error  Condition  -  The  short  title  is  indented  5 

or  more  spaces. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  FORMAT  LINE 
CONTINUATION".  See  Message  Error  Processing  for  the  appropriate 
response . 

£.3. 8. 1.4  Check  1 0 . 1 . d .  -  The  short  title  to  be  exempted  is 

an  OTC  addressee. 

Error  Condition  -  The  guard  command  number  for 
the  short  title  is  greater  than  the  maximum  allowed. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "DATA  BASE  INCORRECT 
FO.P  XXXX...XXX".  See  Message  Error  Processing  for  the 
appropriate  response. 


13*?  occur 


u  1  n  e  s  , 


D  .3.9.1  Format  Line  10  (FLIP)  Processing.  -  FLIO  is  the 

identified  by  the  prosign  "ACCT"  or  by  a  "GR"  followed  by  either 
"NC"  or  a  number. 

Error  Condition  -  None. 

Error  Resolution  -  N/A 


6  .3.10 


MODIFIED  ACP  126  End  of  .Header  Line, 


\bkG3 


;■ ; V V/:.  ;  -  / 


•  r 


*  S.JO.I  Format  \_in^  1  \ _ (.FLVi)  (^rocKS.'S. >ng ■  HeacXe-r  ^^c\ 

heading  validation  is  conciu_L;ru  wheii  the  lirst  "BT''  is 
identified.  The  first  "BT"  or  FLil  separates  the  heading  froir. 
the  classification  and  text  of  the  message.  If  a  valid  "ET"  is 
found,  message  validation  continues  with  FL12  processing.  If  an 
invalid  or  no  "BT"  condition  exist,  the  message  is  rejected  to  a 
service  position  for  the  appropriate  action. 


6  .3.10.1.1  Check.  12 . 1 .  a .  -  Check  for  the  prosign  "BT"  , 

indicating  FLU. 

Error  Condition  -  A  "BT”  has  been  found,  but  the 
message  has  no  FL7/8. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  BT".  See 
Message  Error  Processing  for  the  appropriate  response. 

g. 3. 10.1.2  Check  12 . 1 . b .  -  All  NAVY  originated  traffic 

destined  for  Commercial  Refile  must  contain  a  valid  FLIO. 

Error  Condition  -  The  message  contains  a 
Commercial  Refile  RI  but  a  valid  FLIO  was  not  found. 

Error  Resolution  -  Build  a  FLIO  in  the  form  "ACCT 
NA-CNRF"  and  insert  it  into  the  messaae  orior  to  FLU. 


e  .  3 . 11 


Modified  ACP  126  FL2 ,  FL4 ,  and  TARE  Line  Generation. 


3.3.11.1  Build  a  "NEPJ"  FL2.  -  FLU  triggers  this  processing 
because  at  this  point  all  addressee  processing  ceases.  The 
necessary  ?.I(s)  have  been  saved,  or  eliminated  by  FL9  and  "T 
Zt-TL"  processing  so  that  all  remai.ns  that  are  required  RI(s)  (up 


to  a  maxim.um 


iOO).  The  saved  RI( s )  are  sorted  and  duplicates 


removed.  Each  RI  is  then  interrogated  for  TRC  requirements,  and 
a  count  kept  of  the  total  TRCs  so  that  the  num^ber  of 
transmissions  may  be  calculated.  The  TRC ( s )  is/are  then  moved 
into  the  proper  position  in  the  FL2  security  redundancy  field. 
Upon  completion  of  examination,  the  RI(s)  is/are  moved  into  FL2 
following  the  SOR  sentinel  while  keeping  track  of  line  maximums. 
Once  the  last  RI  has  been  processed,  an  EOR  delimiter  is  moved 
in  place.  At  this  point  the  RxxxSUU,  Modified  ACP  126 
ide.ntifier,  is  erased. 


Additionally,  the  generated  OSRI  and  SSN  which 
were  mentioned  under  FL2  processing,  overlay  the  original  FL2 
information.  The  original  message  ide.ntity  is  .not  lost  however 
since  all  pertinent  data  has  been  stored,  along  with  the  newly 
ge.nerated  data,  in  a  history/  file. 


*0.3.11,1.1  Check.  lZ.3..-a-,  -  RlXT  lils  ore.  net  3L\o'»jet\  "Vc 

possess  a  "Y"  or  "Z"  device  character. 

Error  Condition  -  A  RIXT  RI  contains  the  letter 
"Y"  or  "Z"  as  its  seventh  character. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  7TH 
CHARACTER  IN  RIXT  RI".  See  Message  Error  Processing  for  the 
appropriate  response. 


>0^ .  3 . 1 1 . 2  Format  Line  4 

stored  in  the  message  hi 
message  classification,  FL4 
classification,  it  is  de 
"ZNY"  is  to  be  used,  then 
Depending  on  the  presence  o 
or  five  classification  char 
moved  i.nto  place  using 
security  redundancy  field  a 
are  pulled  from  the  mes 
newly  built  FL4 ,  five  redun 
by  slashs. 


Generation .  -  Using  the  information 
story  file  concerning  TRCs,  SHDs ,  and 
is  rebuilt.  Based  upen  message 
termined  whether  the  prosign  "ZNR"  or 
inserted  after  the  EOR  delimiter, 
r  absence  of  a  TRC,  a  space  and  three 
acters  are  added.  The  TRC(s)  are 
the  last  two  characters  or  the  FL2 
s  a  guide.  Next,  any  existing  SHDs 
sage  history  file  and  appended  to  the 
dant  characters  at  a  time  separated 


Error  Condition  -  None. 


Error  Resolut ion  -  N/A 


e.3. 

the 
gene 
proc 
1  ?  ■''  1 


11.3  TARE  Line  Generatlo.n.  -  T.ARE  lines  are  built  using 

sorted  Rl/Short  Title  identifier  table  created  by  the  FL2 
rator.  The  short  title  identifier,  saved  during  FL7  and  8 
essing,  not  only  indicates  whether  a  TARE  line  should  be 
t  for  this  particular  entry  but  also  where  to  find  the  fully 
ified  PLA  or  short  title  spelling.  TARE  lines  are  generated 
he  forms;  P.xxxx  T  SHORT  TITLE  or  Rxxxxx  T  SHORT  TIITLE 'SHORT 
E/  .  .  .  Since  a  sorted  table  is  used  to  glean  the  TAP.E 
rm.ation,  short  title  ide.ntif ier.s  with  the  same  RI  will  be 
nded  to  the  same  line  as  long  as  line  length  remains  within 
ts . 


j  .  3 . 1 1 . 4  Summary  of  FL2  ,  FL4  ,  and  T.RP.E  Line  Generation  .  - 

Tne  original  message  at  this  point  has  been  modified  to  contain 
a  new  OSRI ,  SSN,  FL4 ,  a.nd  TARE  lines.  As  mentioned  earlier,  the 
.RI  which  identified  the  message  as  .Modified  .RC?  126  has  been 
replaced  by  the  proper  Routing  Indicators.  The  eld  FL4 ,  which 
sould  .not  cc.ntai.n  TRCs  i.n  FL4  processing,  may  .new  possess  them.. 
•Rll  the  original  "T  Z>jL"  and  operating  signal  lines  are 
retained,  and  are  not  overwritten  by  ar.y  generated  li.ne. 


Error  Condition  -  .None. 


Error  Resolution  -  H/A 


.3.12. 


e 

6.3.12.1  Format  Line  12  (FL12)  Processing.  -  When  the  first 
"BT"  or  FLU  has  been  identified  and  processed  without  error, 
format  line  12  (FL12)  is  the  next  line  searched  for.  FL12,  or 
the  classification  line  as  it  is  known,  contains  the  message 
classification  and  it  must  correlate  with  the  security  of  the 
message  identified  in  FL2 ,  FL4 ,  and  any  special  handling 
caveats.  If  the  message  is  "SPECAT" ,  FL12's  security  must  be 
CONFIDENTIAL  or  above.  During  processing,  the  security 
narrative  in  FL12  is  checked  against  a  classification  table  for 
a  match.  Any  discrepancy  results  in  the  message  being  rejected 
to  a  service  position. 

When  "SPECAT"  is  found  in  FL12,  the  message 
itself  must  have  the  appropriate  SPECAT  Release  Code  (SRC)  in 
FL4 .  If  it  does  not,  either  FL4  or  FL12  is  in  error  and  the 
message  is  rejected  to  a  service  postion.  WTien  the  SRC  in  FL4 
contains  the  letter  "A",  then  the  caveat  following  "SPECAT"  in 
FL12  must  be  "SIOP-ESI".  All  other  SPECAT  caveats  are  valid 
when  the  SRC  "B"  is  contained  in  FL4 .  An  error  in  one  of  these 
conditions  will  result  in  the  message  being  rejected  to  a 
service  position. 

When  "SVC"  is  found  in  FL12,  message  delivery  is 
set  for  the  Service  Center. 

WTien  "NOFORN"  is  found  in  FL12,  it  indicates  that 
the  message  is  not  eligible  for  foreign  delivery.  If  a  foreign 
RI  has  already  been  identified  in  FL2  processing,  then  the 
message  is  rejected  to  a  service  position. 

During  FL12  processing  a  search  is  made  for  a 
Navy  Standard  Subject  Identification  Code  (SSIC).  If  a  SSIC  if 
fcund  (i.e.,  //NOOOOO//)  and  further  validation  determi.nes  that 
a  message  SSIC  is  i.ndeed  i.n  the  li.ne,  rhe.n  the  .message  SSIC  is 
saved  for  subsequent  message  distribution  processing. 

A  unique  feature  of  the  LD.“C<  is  that  it  allows 
each  site  to  handle  Special  Handling  Instructions  individually. 
If  special  handling  is  identified  in  FL12,  the  m.essage  will  be 
processed  I.^.W  the  special  instructions. 

Following  the  search  for  sectional  information,  a 
search  is  m.ade  for  the  word  "SUBJ".  "SUEJ"  is  used  as  to 
deli.Tiit  the  end  of  security  and  special  handling  information, 
and  to  identify  the  subject  line  cf  the  message.  "SUBJ"  is 
required  to  be  used  as  a  delimiter  whether  or  not  a  subject  is 
given.  FL12  a.nalysis  shall  persist  for  7  lines,  or  until 
recognition  of  other  lines  that  indicate  the  subject  line  has 
bee.n  omitted.  A  refere.nce  line  ( lef  t- just  if  ied  "A.  ")  or  a 
paragraph  li.ne  ( lef t -  justif  ied  "1.  ")  found  within  7  lines, 
before  finding  "SUBJ",  shall  be  considered  as  evidence  that  the 
"SUBJ"  line  does  .not  exist.  In  such  cases  the  first  physical 
li.ne  shall  constitute  the  bounds  of  security  and  special 
handling  information. 


For  D^SCS /GEVJSEf^  LC)KX  sites  s  phrgse.  sesrck  v  S 
performed  within  the  confines  of  the  ‘'SUEJ”  line  or  the  first  7 
lines,  startina  with  FL12.  If  a  Phrase  is  detected  which  is 
associated  to  the  DSSCS  community  only,  then  an  error  condition 
exists  and  the  message  is  rejected  to  a  service  position. 

Sectioning  requirements  are  calculated  at  this 
point.  Upon  initial  receipt  of  the  message  data  and  prior  to 
actual  validation,  the  LDMX  counted  the  total  number  of  lines 
received.  It  is  this  count,  in  combination  with  the  number 
lines  processed  from  FL5  to  FL12;  and  the  number  lines  which 
were  validated  as  FL2,  FL2  continuations,  FL4  and  FL4E,  that 
enables  sectioning  requirements  to  be  calculated.  The  LDMX  also 
takes  into  account  "mixed"  pages,  those  pages  containing  heading 
and  text  data. 

Once  the  total  number  of  sections  has  been 
determined,  the  number  is  saved  in  the  message  history  file,  and 
is  used  to  indicate  when  sectioning  is  required  and  finished.  A 
section  line  will  be  inserted  following  the  message 
classification  in  the  form:  SECTION  .XX  OF  YY,  where  XX  equals 
current  section  and  YY  always  represents  total  sections. 

Now  that  sectioning  requirements  have  been 
established,  the  counts  mentioned  will  key  when  the  first  and 
subsequent  sections  are  complete.  When  the  counts  indicate  that 
a  section  is  complete,  a  check  is  made  to  e.nsure  that  the  EOM 
sequence  of  the  original  message  is  not  going  to  be  the  only 
data  in  the  rem.aining  section.  If  that  is  not  the  case,  an  EO.M 
sequence  is  generated  at  that  point,  and  the  subsequent  section 
heading  built.  Tne  new  heading  is  basically  copied  from  the 
modified  original  message,  starti.ng  with  FL2  and  ending  with  the 
"SUBJ"  delimiter,  if  one  existed.  The  new  FL2  will  be  changed 
to  include  a  new  SSN. 

.All  line  counts  will  now  reflect  total  lines 
processed  thus  far  i.n  the  new  heading,  and  line  validation 
resuoies  where  it  had  left  off  i.n  TEXT  processing. 

There  are  five  full  textual  pages  in  a  section. 
The  mixed  page  is  not  used  to  compute  pages / section .  A  new 
section  starts  after  the  mixed  page  a.nd  5  pages  of  text. 

Pagi.ng  requireme.nts  a.nd  validations  will  be 
discussed  here  u.nder  FL12  processing  only  for  convenie.nce ,  since 
page  lines  may  also  exist  in  the  heading  of  a  m.essage. 

The  LCyJ<  must  also  keep  track  of  the  .nu.mter  of 
lines  processed  from  FL5  to  the  end  of  the  message  si.nce  paging 
is  required  every  20  li.nes  ,  begining  with  FL5.  .A  page  line  is 
built  every  20th  line  and  will  ccntai.n  all  of  the  appropriate 
i.nf orm.ation  as  set  down  in  the  JAdLA?  123  publication. 

In  addition  to  buildi.ng  page  lines,  existi.ng  page 
lines  are  also  identified  and  stripped  from  the  original  m.essage 


130 


CheclfN  \3.  \ .  a.  —The.  secvjr \y  narrative  .is  check.es^ 
againsr  che  messaae  security  class ii icat i on . 

Error  Condition  -  The  FL12  classification  does 
not  match  FL2;  an  illegal  condition  exists  (i.e.,  special 
handling  instructions  in  a  SPECAT  message);  or  SPECAT  was 
indicated  in  FL4  and  not  found  in  FL12. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  SECURITY 
CLASSIFICATION" .  See  Message  Error  Processing  for  the 
appropriate  response. 

6.3.12.1.2  Check  13 . 1 . b .  -  A  check  is  made  to  see  if  the 

message  is  eligible  for  foreign  delivery. 

Error  Condition  -  "NOFORN"  was  found  in  FL12,  and 
TRCs  are  prese.nt  in  FL4 . 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NOFORN  MSG  ROUTED  TO 
.NON-US  RI".  See  Message  Error  Processing  for  the  appropriate 
response . 

£.3.12.1.3  Check  13.1.C.  -  If  a  DSSCS/GEN5ER  LD.MI':,  a  check 

is  made  for  possible  security  violations  between  communities. 

Error  Condi  tio.n  -  A  DSSCS  phrase  has  been 
detected  i.n  a  GENSEIR  message  during  FL12  processing. 

Error  Resolution  -  The  message  is  rejected 
service  position  with  the  error  annotation  "SI-ONLY  PHR.YS' 

I.N’  GENSER  MSG".  See  Message  Error  Processing  fo 
appropriate  response. 

6  .3.13  MODIFIED  ACP  126  End  of  Messaae  ( EOM )  Lines .  - 

S. 3. 13.1  Format  Lines  13/15/16  ( FL13 /  15 ./ 16 )  Processing.  - 

>Jhen  FL12  processing  is  complete,  the  remaining  message  body  is 
treated  as  message  text  until  the  second  "ET"  or  FL13  is  found. 
When  "BT"  is  found,  EOM  validation  occurs.  k  check  is  made  to 
determine  the  number  of  li.nes  remaining  in  the  message.  If  m.cre 
than  2  lines  remain,  then  an  error  is  assumed  and  the  m.essage  is 
rejected  to  a  service  position.  If  the  "ET"  appears  oc  be  in 
the  proper  location,  then  FL15  is  validated.  FL15  begins  with 
the  sign,  and  if  it  is  not  present  an  error  is  assumed  and 

the  message  is  rejected  to  a  service  position.  If  the  '  sig.n 
is  present,  then  the  SEN  in  FL15  is  validated  to  be  .numeric  a.nd 
match  the  FL2  SSN  of  the  original  .message.  Straggler  valid.aticn 
checks  must  be  done  using  the  original  m.essage  data  and  not  the 
data  generated  by  Modified  AC?  126  processing.  In  the  case  of  a 
valid  FL15,  the  SSN  generated  during  FL2  processing  or  section 
processing  replaces  the  original  SSN.  Now  the  Modified  FL2  SSN 
.matches  the  EO.M  SSN.  After,  FL15  validation,  the  last  line  in 


to  a 

0 


vs  the  Cnee  if  tl^e  ex'sei"  n^'tchv  .\s  nci 

found  an  error  ' s  assumed  and  the  message  is  rejected  to  a 
service  position. 

After  EOM  validation  the  message  is  considered 
processed  and  placed  in  the  appropriate  transmission  queues 
"FIFO"  by  precednece  for  delivery. 


6.3.13.1.1  Check  14.1. a.  -  Check  the  message  for  a  second 

"ET"  (EOM  indicator). 

Error  Condition  -  There  are  only  2  lines  of  data 
left  in  the  message  and  the  second  "BT"  has  not  been  found. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "NO  BT  F/L  13".  See 
Message  Error  Processing  for  the  appropriate  response. 

6-3.13.1.2  Check  14 . 1 . b .  -  The  second  "ET"  has  been  found, 

and  the  next  line  must  be  FL15. 

Error  Condition  -  The  sign  is  missing  or  the 

4  digits  following  the  sign  are  not  numeric. 

Error  Resolution  -  The  message  is  rejected  to  a 
service  position  with  the  error  annotation  "INVALID  F/L  15". 
See  Message  Error  Processing  for  the  appropriate  response. 


6.3.13.1.3  Check  14 . 1 . c .  -  FL15  is  present  and  the  last  line 
must  contain  only  the  characters  "NNNN" . 

Error  Condi tic.n  -  The  line  following  FL15  does 
not  contain  exactly  "NNNN". 


service  cosition 


Error  Resolution  -  The  message  is  rejected  to  a 
on  with  the  error  annctatio.n  "INV.-.LID  F/L  16". 


See  Message  Error  Processing  for  the  appropriate  respo.nse. 


6.4,0 

6.4^ 


AUTOVAATiC  SERVICE  COHfiO51T>O)0  "SCC'  PROCESSING. 
General  Cor.ments .  - 


1  •  1  (Fleet  Router  Processing?)  "SCC"  processing  is  invoked 

when  the  RI ,  "RxxxSCC"  is  contained  in  FL2  and  should  be 
considered  as  a  continuation  of  JANAP  128  message  processing. 
"RxxxSCC"  is  defined  as  an  RI  that  the  LDMX  recognizes  as  one 
for  which  it  has  accepted  delivery  responsibility.  As  already 
mentioned,  FL4/7/8  saved  each  short  title  ide.ntifier  that 
required  rerouting.  OTC  short  titles  did  not  qualify  as 
requiring  retransmission  since  they  may  be  delivered  locally. 

Upon  validating  FL16  of  a  JANAP  128  message,  the 
ZOV  pilot  generation  begins.  This  involves  making  an  entirely 
new  message  by  copying  and  modifying  the  original  message. 
"SCC"  processing  will: 

1.  Change  LMFl  to  LDMX  input  LMF  of  "T". 

2.  Change  the  CIC  to  "ZOn-I"  if  the  original  CIC 
was  "ZYUt-J"  otherwise  no  change  is  made. 

3.  Change  the  OSRI  to  reflect  the  LDMX  service 

center  RI. 

4.  Change  the  TCF  to  reflect  time  of  ZOV  pilot 

generation . 

5.  Replace  the  existing  FL2  RIs  with  the  RIs  of 
the  short  titles  that  are  being  Rerouted. 

6.  Assign  TRCs  where  applicable. 

7.  Strip  off  any  existing  FL3  through  FL4/E 
since  these  lines  are  to  be  resuilo. 

S.  Add  to  FL4  she  "LOV"  ccsig  fcllowed  by  the 
LDfdX  service  ce.nter  RI  and  generated  SSN,  the  words  "Reroute  OF" 
and  the  OSRI,  SSN ,  and  TOF  that  appeared  in  the  original  message 
FL2  or  FL3. 


9.  TAF.E  instructions  identifying  the  short 
titles  requiring  Reroute  are  added.  The  RIs  for  these  short 
titles  are  retrieved  from  the  data  base  usi.ng  the  message 
classification  as  the  criterion. 


♦  < 

.*•> 

•A 


8.4.2 


Valida t ion/ Verif icat ion  Re 


..  tg  « .  u.  o  I 
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.  1  Motrt  6-''  rors  c,r\ccLrv+er«c^. 'csAm \e.  creux  i  \K<e 

will  only  terrainate  the  ZCV  message  and.  never  the  originax 
message.  Detected  errors  are  annotated  with  the  appropriate 
error  notice  and  forwarded  to  the  Service  Center. 


6  4/2.1.1  ^  Check  1.1.  a.  -  In  order  to  persue  ZOV  pilot 
generation,  the  original  message  history  file  must  contain  valid 
ormat  lines  2,  3  (when  required),  5,  and  16. 

Error  Condition  -  When  scanning  the  original 
message's  history  file  for  a  valid  FL2,  an  invalid  pilot  FL2  was 
found  or  a  valid  FL2  was  not  found. 

Error  Resolution  -  The  ZOV  message  is  not  built 
and  a  copy  of  the  original  message  is  dropped  to  a  service 
position  with  the  annotation  "AUTOMATIC  ZOV  WILL  NOT  BE 
PERFORMED  -  NO  FL2  FOUND  IN  THE  ORIGINAL  MESSAGE".  The  message 
requiring  the  ZOV  must  be  manually  Rerouted. 

Error  Condition  -  The  original  FL2  was  found  and 
the  LMF  indicated  that  the  message  should  contain  a  FL3 .  The 
search  for  a  valid  FL3  was  unsuccessful. 


Error  Resolution  -  The  ZOV  message  is  not  built 
and  a  copy  of  the  original  message  is  dropped  to  a  service 
position  with  the  annotation  "AUTO.MATIC  ZOV  WILL  NOT  BE 
PERFORMED  -  NO  FL3  FOUND  IN  THE  ORIGINAL  MESSAGE".  The  message 
requiring  the  ZOV  must  be  manually  Rerouted. 

Error  Condition  -  In  the  process  of  trying  to 
append  the  rest  of  the  original  message  to  the  newly  created  ZOV 
pilot  lines,  a  valid  FL5  could  not  be  found. 


a.nd  a  copy 
cos  it  ion  wi 
PERFORMED  - 
requring  the 


Error  Resolution  -  Tb.e  ZOV  message  is  not  built 
of  the  original  messacre  is  drocced  to  a  service 
th  the  annotaticn  "AUTCMA.TIC  ZOV'  WILL  NOT  BE 
NO  FL5  FOUND  IN  THE  ORIGINAL  MESSAGE".  The  message 
ZOV  must  be  manually  Rerouted. 


642.1.2  Check  l.l.b.  -  Before  a  proper  ZOV  pilot  can  be 
built,  "SCC"  processing  must  produce  all  the  correct  routing 
assig.nments  and  TARE  lines. 

Error  Condition  -  During  the  retrieval  of 
"cleared"  RI(s)  for  a  short  title  requiri.ng  Reroute,  no 
"cleared"  RI(s)  could  be  found. 

Error  Resolution  -  Processing  continues  however 
a.n  error  notice  is  appe.nded  to  the  ZOV  message.  The  error 
notice  is:  "NO  CLEAREID  RIs  FOR  XIGd .  .  . XIGd "  .  The  error  will  be 
displayed  at  a  service  positio.n  upon  the  completion  of  "SCC" 
processing . 


Error  Condition  -  Duri.ng  the  creation  of  the  ZOV 
t  is  discovered  that  there  were  no  RIs  aenerated. 


cilot,  i 


6.5.0 

6,51 


KFrtOJE_  entry. 

General  Corr.r.ents.  - 


051.1  This  section  deals  with  the  LDMXs  capability  to 
process  preformatted  automatic  recall  or  retransmission  request, 
hereafter  referred  to  as  "SRR"  processing. 

"SRR"  processing  allows  remote  subscribers,  such 
as  the  Remote  Information  Exchange  Terminals  (RIXT)  to  retrieve 
messages  from  the  LDMX  online  storage  files  which  were  addressed 
to  the  terminal  or  a  subscriber  served  by  that  terminal.  "SRR" 
request  may  also  be  entered  from  an  interactive  VDT  at  the  LDMX. 

6,5.2  Validation/Ver  if  i  cat  ion  Requirements  .  - 


652.1  Format  Line  1  -  Transmission  Identifier  Line.  -  Since 

the  interface  between  the  RIXT  terminals  em,ploy  their  own 
protocol,  called  the  "LDMX  IXS/RIXT  Protocol",  no  formal 
validation  of  TI  information  is  performed.  If  the  RIXT  control 
block  contains  a  CD-CSN,  it  will  be  used  to  update  the  LDMX 
local  tables,  otherwise,  the  LDMX  CSN  will  be  updated  with  the 
next  message  sequence  expected.  In  either  case,  no  error 
conditions  are  noted  for  TI  line  processing. 


0.j;3  "SRR"  .Message  Format.  -  For  NAVY 

validation/verif ication  purposes,  the  "SRR"  format 
into  three  parts:  Header  data  including  the  Routing 
(RI)  field  (Format  Line  2);  Recall  parameters;  and 
Message  (EOM)  line. 


LD.MX 
is  divided 
Indicator 
the  End  of 


^/?3.1  "SR.P."  Form, at  Line  2  Processing.  -  Form.at  line  2  (FL2) 
Gf  a  recall  request  is  form.atted  identically  to  that  of  a  J.ANAP 
12S  message.  The  RI  is  unique  tc  the  LDMiX,  in  that  it  cc.ntai.ns 
the  local  LDMX  NARC  (i.e.,  Rxxx)  and  the  derivative  "SR.P.",  thus 
the  only  RI  contained  in  FL2  is  "RxxxSRR" , 

Si.nce  the  sam.e  basic  FL2  checks  m.ade  on  a  JAITAP 
message  are  m.ade  for  a  "SRR"  miessage  they  will  not  be  discussed 
here  in  detail.  The  exceptions  will  be  discussed,  but  not  at 
the  level  of  ERROR  CONDITION/ERROR  RESOLUTION. 

When  a.n  error  in  FL2  is  encountered,  an 
abbreviated  plaindress  service  message  is  generated  back  to  the 
origi.nator  (i.e.,  RIXT  input  device)  identifyi.ng  the  message  in 
error  a.nd  the  reason  for  rejection.  A.  copy  of  the  "SRR"  request 
and  the  reason  for  rejection  is  also  delivered  to  the  Service 
Center . 

If  no  FL2  errors  are  detected  prior  to  the  RI 
field,  and  the  RI  field  contains  the  RI  "RxxxSRR"  followed  by 
the  End  of  Routing  (EOR)  character,  the  remainder  of  the  message 
is  processed’as  a  recall / retransmission  request. 


6.5j3.2«  Recall  I  /Retrsnsn\'>ss \ori  iTe.+g r (s )  ,  -  P\ff^r  ECR 

has  been  identified  the  next  line  to  oe  validated  is  the  recall 
parameters.  Various  parameters  rancre  from:  PSNA.  XM^Z'-IXM 

(XXXXXX  =  6  DIGIT  PSN),  ODTG,  SHORT  TITLE/ / 01 OOOlZ  JAR  83, 

OSRI.  RxxxxxxOOOl  0010001,  etc.  The  recall  parameter  and 
arguments  are  checked  against  an  allowable  recall  table  and  if 
the  recall  parameter  is  valid,  the  request  is  processed  and  the 
message  that  was  requested  is  retransmitted  with  a  "ZDK"  header. 
The  header  includes  the  "ZUI"  information  necessary  for  the 
originator  to  reference  the  recall  request. 

If  the  parameter  or  it  arguments! s)  is  in  error 
the  message  is  rejected  to  the  Service  Center  with  the 
appropriate  annotation  and  an  Automatic  service  message  is  sent 
to  the  originator  with  the  reason  for  rejection.  The  originator 
at  this  point,  would  correct  the  recall  request  and  resubmit  to 
the  LDMX. 

RIXT  terminals  have  the  capability  to  retrieve 
data  base  information  for  their  particular  comimand.  This  is 
also  accomplished  through  "SRR"  processing.  For  example,  if  a 
RIXT  terminal  wished  to  obtain  LDMX  guide  file  information  for 
guard  com.mand  one,  the  recall  parameter  would  be  "GUID.  SHORT 
TITLE//CMJD  NR".  The  LDMX  would  validate  the  request  and  that 


ensure  the  RIXT  terminal  is  associated  to 
which  requested  the  inf orm.ation. 

the 

guard 

command 

For  readdressal  processi.ng. 

the 

RIXT 

terminal 

passes  a  new  header,  which  after  all  validation  is  complete, 
will  precede  the  header(s)  on  the  original  message.  In  all 
cases,  if  errors  occur  during  parameter  validation,  the 
originator  is  informed  of  the  error  and  the  message  is  rejected 
to  the  Service  Center. 


5’, 5.2.3  End-of -Message  (EQM)  Line.  -  After 

parameter  li.ne  has  been  validated  the  las! 


recall 


recussi 


I  13  tnc  EOM .  EOM  will  ccr.i^in  4  cir.d  r^o 

data.  Unlike  J.ATJA?  processing,  a  FL13  and  FL15  are  not 


required.  If  the  4  "N"s  are  not 
"N"s  is  detected,  the  recall 
originator  is  so  informed. 


s  are  not  found  or  data  other  tha.n  the  4 


reuues: 


error  and  the 


7.0 


DPI  103  Format  Message  Processing  Requirements 


fs 

^.1.  General  Comments. 

‘.1.1.  This  section  will  detail  the  existing  AUTODIM  processing  as 
it  applies  to  DPI  103  message  formats  utilized  by  most  of  the  DSSCS 
community  subscribers.  As  with  the  JAXAP  128  and  AGP  127  message 
formats  processing  requirements,  these  checks  and  validations  must 
be  carried  forward  in  the  I-S/A  .-^MPE  program  to  ensure  that  the 
message  integrity  currently  provided  is  maintained. 

* .2 .  Validation  Requirements 

7.2.1.  Format  Line  1  -  Transmission  Identifier  (TI)  Line.  I-S/A 
AMPE  validation  of  the  TI  line  is  identical  for  both  asynchronous 
(Mode  II  and  V  teletypewriter  terminals  whose  use  of  a  TI  line  is 
mandatory)  and  synchronous  (Mode  I  users  who  employ  line  block 
framing  and  whose  use  of  a  TI  line  is  optional  but  must  be 
specified  at  the  time  the  I-S/A  .AMPE  sets  the  port/channel 
parameters)  channels.  All  TI  lines  through  the  CD-CSN  fields  are 
processed  as  follows: 

7. 2. 1.1.  The  first  characters  of  the  TI  line  block  must  be  a  Start 
of  Header  (SPH)  and  a  select  (SEL)  character.  If  the  channel  is 
asynchronous,  these  have  been  inserted  by  the  I-S/A  A^IPE;  if  the 
channel  is  synchronous,  the  terminal  has  inserted  them. 


7.2. 1.2.  Check  1.1. a.  The  first  data  character  of  the  TI  line 
must  be  the  letter  "C".  (If  the  channel  is  asynchronous,  the  "ZCZ" 
portion  of  the  Start  of  Message  Sequence  (SOMS)  was  previously 
validated  and  then  discarded  by  the  I-S/A  AMPE.) 

Error  Condition  -  None  -  nothing  can  be  recognized  prior 
to  receipt  of  the  SOH. 

Error  Resolution  -  N/A 

7.2. 1.3.  Check  1.1. b.  The  second,  third  and  fourth  characters  of 
the  TI  line  must  be  the  Channel  Designator  (CD)  and  must  match  the 
CD  stored  at  the  I-S/A  AMPE  for  that  port /channel. 

Error  Condition  -  A  CD  is  considered  to  be  in  error  if  it 
does  not  match  the  CD  stored  in  the  I-S/A  AMPE  for  its'  associated 
channel. 

Error  Resolution  -  All  DOI  103  formatted  messages  having 
CD  errors  will  be  rejected  and  an  "INVALID  CD”  service  message 
automatically  generated  to  the  input  port/channel.  (CRITIC  format 
is  unique  and  not  considered  DOI  103  format  for  the  purpose  of 
these  checks.) 

7.2. 1.4.  Check  l.l.c.  The  fifth  character  of  the  TI  line  can  be 
either  a  figures  shift  or  the  first  character  of  the  CSN  field;  the 
figures  shift  must  be  present  for  "A”  Select  (ITA  2)  messages  and 
may  or  may  not  be  present  for  other  selects.  Note  that  for  all 
processing  purposes,  "A"  Select  CSN's  are  always  assumed  to  begin 
in  the  sixth  position  of  the  TI  line.  This  is  done  so  that  the 
"CSN"  to  be  quoted  back  to  the  terminal  in  a  service  message  will 
be  positionally  correct  even  if  the  figure  shift  is  garbled, 
leaving  the  CSN'  field  in  the  lower  case.  If  the  CSN  is  correct,  TI 
line  processing  is  complete  at  this  point. 

Error  Condition  -  A  CSN  is  considered  to  be  in  error  if  it 
is  either  non-numeric  or  if  it  is  not  the  next  expected  CSN  (i.e., 
one  greater  than  the  last  accepted  from  a  Mode  V  port/channel  or 
received  from  a  Mode  I  or  II  port/channel.  For  this  purpose,  a  CSN 
of  000  is  considered  to  be  one  greater  than  99^. 

Error  Resolution  -  Messages  of  CRITIC  precedence  will  be 
accepted  regardless  of  CSN  errors  detected.  Other  messages  having 
CSN  errors  will  be  processed  as  follows: 

If  the  CSN  is  a  duplicate  of  the  last  accepted  (Mode 
V)  or  received  (Mode  l/ll),  the  message  will  be  rejected  to  the 
input  port/channel.  This  is  the  only  instance  of  CSN  error  where  a 
message  will  bo  rejected  by  the  I-S/A  A^iPE  which  will  automatically 
generate  an  "IN'/ALID  CSN”  message  to  the  input  port/channel  and  log 
the  error  condition  on  an  error  file  for  future  compilations 
(possibly  similar  to  the  existing  Communications  Improvement 
Memorandum  (CIM)  program. 

If  the  CSN  is  incorrect  for  any  other  reason 


including  being  non-numeric,  the  message  will  be  accepted. 

However,  these  errors  shall  cause  the  I-S/A  AMPE  to  automatically 
generate  a  service  message  to  the  input  port/channel  citing  the  CD 
and  CSM  as  well  as  other  pertinent  message  identification  data. 

This  service  message  will  indicate  "INVALID  CD",  "INVALID  CSN"  and 
whether  the  message  was  accepted  or  rejected.  A  duplicate  CSN  will 
cause  generation  of  an  additional  service  message,  "DUPE  CSN”. 
Missing  CSNs  will  cause  automatic  generation  of  an  open  number 
(ZFX)  service  to  the  input  port/channel. 

7. 2. 1.5.  Further  I~S/A  AMPE  TI  Line  processing.  In  order  to 
maintain  CSN  continuity  between  the  I-S/A  AMPE  and  the  terminal, 
the  I-S/A  AMPE's  tables  are  updated  based  on  the  results  of  CSN  and 
message  processing.  IVnen  a  CSN  is  rejected  (i.e.  ,  duplicate 
condition),  no  CSN  updating  is  performed. 

ivhen  a  CSN  is  accepted,  even  if  it  is  out  of  sequence,  the 
accepted  CSN  (or  the  expected  CSN,  if  the  received  CSN  is 
non-numeric)  is  made  the  last  accepted  CSN  for  processing  of  future 
messages.  When  the  channel  is  Mode  I  or  Mode  II  this  update  is 
done  immediately  on  receipt  of  the  TI  line  whether  the  associated 
message  is  accepted  or  not,  since  the  Mode  I  nr  Mode  II  terminal  is 
assumed  to  update  the  CSN  at  the  beginning  of  each  message 
transmission.  This  is  also  consistent  with  a  terminal  transmitting 
a  tape  in  which  there  are  pre-cut  CSN's  preceding  each  message. 
Since  Mode  V  procedures  require  that  CSN's  be  updated  on  acceptance 
of  the  message.  Mode  V  terminal  equipment  does  not  update  its  TI 
generator  until  the  associated  message  has  been  acknowledged  by  the 
I-S/A  AMPE.  Consequently,  the  I-S/A  AMPE  also  does  not  update  the 
last  accepted  CSN  on  a  Mode  V  channel  until  the  message  has  been 
validated  and  accepted,  and  the  ACK  for  the  message  has  been  sent 
to  the  terminal. 

.3.  Format  Line  2  -  Message  Header.  For  I-S/A  AU'PE 

validation  purposes,  the  DOI  formatted  header  is  divided  into  three 
parts:  Header  data  up  to  and  including  the  Start-of-Rout ing 

Sequence  (Format  Line  2);  the  Routing  Indicator  Field  (still  a  part 
of  Format  Line  2);  and  the  Security  Line  (Format  Line  4), 


■<’•3.1.  Header  Validation/Verification  Through  the 
Star  t-of-R.out  in.t. 

'.3.1.1.  Precedence  Field.  The  first  header  field  to  be  validated 
is  the  precedence  field.  It  should  be  noted  that  even  though  the 
TI  line  is  the  first  data  received  from  the  port ''channel ,  it  is  not 
the  first  messa'^e  area  to  be  processed.  The  precedence  field  is 
processed  first  since  the  precedence  of  the  message  affects  the 
decision  on  whether  to  accept  a  TI  line  with  errored  fields. 

.3.1.1.!.  Che ck  2 . 1 . a .  Precedence  is  a  single  character,  the 
first  character  of  the  header  and  is  validated  to  be  one  of  four 
characters : 

"2"  -  Flash 
"0"  -  Immediate 


"P"  -  Priority 

"R"  -  Routine 

Error  Condition  -  If  the  field  is  not  one  of  the  four 
precedence  characters  specified  above. 

Error  Resolution  -  An  error  in  the  precedence  field 
of  either  an  invalid  or  an  unauthorized  character  results  in 
message  rejection  on  all  except  Mode  II  channels  where  the  Invalid 
precedence  character  is  replaced  by  an  "0"  (immediate)  and  the 
message  processed  at  that  precedence  level.  Errors  in  the 
precedence  field  which  cause  rejection  result  in  the  automatic 
generation  of  an  "INVALID  HEADER"  error  condition  to  the  input 
por t/channel. 

?.3.1.2.  Language  Media  Format  (LMF).  The  next  field  to  be 
validated  in  a  DOI  formatted  message  is  the  Language  and  Media 
Format  (LMF)  field.  This  is  a  two  character  field  in  which  the 
first  character  (LMFl)  indicates  the  medium  in  which  the  input 
message  was  originally  prepared.  It  is  sometimes  also  called  the 
Input  LMF  or  ILMF.  The  ILMF  must  be  consistent  with  the  select 
character  (SEL) .  The  second  character  (LMF2)  indicates  the  medium 
in  which  the  originator  prefers  the  message  to  be  delivered  to  the 
addressee.  It  is  sometimes  also  referred  to  as  the  Output  LMF 
(OLMF)  or  Preferred  Output  LMF  (POLMF).  Input  header  processing 
merely  validates  the  SEL/LMF  combination.  Further  use  of  the  LMF 
in  input  processing  and  in  output  message  delivery  will  be 
discussed  later. 

.%3. 1.2.1.  Check  2. 2. a.  In  the  I-S/A  AliPE,  the  LMF  pair  will 
never  be  validated  separately.  LMF  Validation  is  always  combined 
with  validation  of  the  SEL,  and  the  three  characters  are  validated 
together.  If  the  message  is  from  a  TI  user,  the  SEL  is  obtained 
from  the  second  framing  character  of  the  TI  line  block.  Otherwise, 
it  is  the  second  framing  character  of  the  header  line  block.  Once 
the  SEL-LM?  combination  passes  validation,  the  LMF  pair  information 
is  saved  for  RI  processing,  which  must  determine  whether  a  message 
of  the  specified  LiF  can  be  delivered  to  a  given  RI. 

Error  Condition  -  If  the  SEL/LMF  combination  does 
not  match  any  I-S/A  AMPE  table  entry,  the  SEL  is  validated 
separately. 

Error  Resolution  -  If  the  SEL  is  invalid,  the  message 
is  rejected  and  a  "REPROTECT  TO  ALL  ADDRESSEES"  service  message  is 
automatically  generated  to  the  input  port/channel. 

If  the  message  is  high-precedence  (Cat  I)  and  not 
magnetic  tape,  the  LMF  field  is  corrected  to  make  the  invalid 
LMF(s)  the  most  common  ones  for  that  SEL  ("T"  for  "A"  Select,  "A" 
for  "H"  Select,  "C"  for  ”D"  Select).  If  LMFl  is  valid  and  is  "H", 
"E",  or  "R" ,  an  invalid  LMF2  is  made  "C" ,  "A",  or  "T"  respectively. 

When  the  SEL  is  valid,  but  one  of  the  LMF  characters 
is  invalid,  a  test  is  made  of  the  message  precedence  and  of  the 
SEL.  If  the  message  has  a  SEL  of  "B"  or  "C"  (magnetic  tape),  or  is 


of  low  precedence,  it  is  rejected,  with  an  "IN\’ALID  HEADER"  service 
message  being  automatically  generated. 

7.3. 1.3.  Single  Security  Character  Field.  The  next  field  to  be 
validated  is  the  single  character  security  field  which  must  be  the 
character  "M"  for  DOI  formatted  messages. 

^.3.1.3.!.  Check  2. 3. a.  The  single  character  is  checked  to  be 


Error  Condition  -  Dectection  of  a  character  other 

than  "M". 

Error  Resolution  -  The  message  is  rejected  and  an 
"Ih"v'ALID  SECLUITY  FIELD  -  SEC"  serlvce  message  is  automatically 
generated  to  the  input  port/channel. 

7. 3. 1.4.  Content  Indicator  Code  (CIC)  Field.  The  four  character 
CIC  field  (also  called  the  Communications  Action  Identifier  field 
when  it  contains  communications  instructions)  contains  information 
related  to  the  type  of  message  being  processed.  See  Appendix  19A 
for  specific  additional  codes  and  required  action. 

7.3. 1.4.1.  Check  2. 4. a.  If  the  message  has  a  SEL  of  "A", 
indicating  preparation  in  ITA2  paper  tape,  and  the  CIC  contains  a 
numeric  character  in  the  fourth  character  position,  the  appropriate 
shift  characters  must  precede  (SO/FIGS)  and  immediately  follow 
(SI/LTRS)  that  character. 

Error  Condition  -  Absence  of  the  necessary  shifts 
indicates  that  the  message  preparation  medium  does  not  conform  to 
the  select  character 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  HEADER"  service  message  is  automatically  generated  to  the 
input  port/channel. 

'?.3.1.4.2.  Check  2.4.b.  The  CIC  is  validated  to  be  four 
alphabetic  characters  or  three  alphabetic  and  one  numeric 
character . 

Error  Condition  -  Any  non-alphabet ic  character  in  any 
of  the  first  three  character  positions. 

Error  Resolution  -  The  message  is  rejected  and  an 
"i;rvALID  HEADER"  service  message  is  automaticallv  ;enerated  to  the 
input  port/channel. 

7. 3. 1.5.  Separa tor .  The  character  following  the  CIC  field  must  be 
a  space  (teletypewriter  space,  card  no  punch). 

3. 1.5.1.  Check  2. 5. a.  Check  the  character  following  the  CIC 
field. 

Error  Condition  -  Any  character  other  than  1  space 


character 


Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  HEADER"  service  message  is  automatically  generated  to  the 
input  port/channel. 

7. 3.1.6.  Originating  Station  Routing  Indicator  (OSRI)  Field. 
Following  the  separator  is  the  seven  character  OSRI  field.  This 
may  be  a  seven  character  RI  or  a  six  character  R1  and  a  space. 

7. 3. 1.6.1.  Check  2. 6. a.  The  OSRI  must  be  a  valid  Rl  and 
generally  is  validated  in  the  same  manner  as  a  destination  RI , 
i.e.,  all  characters  must  be  alphabetic;  the  relay  portion  of  the 
RI  (first  four  characters)  must  be  valid;  if  the  relay  portion  is 
the  local  I-S/A  AMPE,  the  next  two  characters  are  checked  for 
validity  and  the  seventh  character  is  verified  to  be  either  an 
alphabetic  character,  a  space,  or  a  shift  out  (figures)  character. 

Error  Condition  -  The  OSRI  is  invalid  or,  if  a  six 
letter  OSRI  is  used,  a  space  character  or  shift  out  (figures)  is 
not  used  in  the  seventh  position. 

Error  Resolution  -  Any  error  in  the  OSRI  field 
results  in  message  rejection  and  an  "INVALID  HEADER"  service 
message  being  automatically  generated  to  the  input  port/channel. 

7  .3.1.7.  Originating  Station  Serial  Number  (OSSN)  Field. 

Following  the  OSRI  is  the  four-character  OSSN  field.  After  the 
alphabetic  OSRI,  an  upshift  (SO/FIGS)  is  required  on  "A"  select 
messages  No  upshift  is  allowed  with  other  selects.  The  OSSN  is 
validated  to  be  four  numeric  characters,  and  messages  which  fail 
this  check  are  rejected  for  "INVALID  HEADER".  A  valid  OSSN  is 
saved  for  later  comparison  with  the  Trailer  Station  Serial  Number 
(ISSN)  at  the  end  of  the  message  to  ensure  that  a  "straggler" 
condition  does  not  exist.  Straggler  checking  is  described  in 
detail  under  End  of  Nessage  validation. 

7. 3. 1.7.1.  Check  2. 7. a.  Check  "A"  SEL  messages  for  in  upshift 
(SO/FIGS)  after  the  alphabetic  OSRI  or  space  character.  If  a  six 
letter  OSRI  is  used,  the  next  two  characters  are  interchangeable  - 
either  a  space  and  a  shift  out  character,  or  a  shift  out  character 
and  a  space. 


Error  Conditions  -  If  an  upshift  (SO/FIGS)  is  not 
present  on  "A"  select  messages  or  if  an  upshift  is  present  on  any 
other  type  of  message. 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  HL-\DER"  service  message  is  generated  to  the  input 
port/channel . 

*<.3. 1.7. 2.  Check  2.7.b.  The  OSSN  shall  be  validated  to  be  four 

numeric  characters. 

Error  Condition  -  The  OSSN  is  not  four  numeric 

iHo 


characters . 


Error  Resolution  -  The  message  is  rejected  and  an 
"IN'VALID  HEADER"  service  message  automatically  generated  to  the 
input  port/channel . 

7. 3. 1.8.  Separator.  A  space  character  separator  (teletypewriter 
space,  card  no  punch)  must  be  present  following  the  OSSN. 

7. 3. 1.8.1.  Check  2. 8. a.  Check  for  space  character. 

Error  Condition  -  No  space  character  following  the 

OSSN. 

Error  Resolution  -  An  error  in  the  separator  field 
results  in  message  rejection  and  an  "IN'VALID  HEADER"  service 
message  being  automatically  generated  to  the  input  port/channel. 

7. 3. 1.9.  Tlme-of-File  (TOE)  Field.  Validation  of  the  TOP  field  is 
the  same  as  that  for  the  OSSN  field  except  that  a  seven-character 
field  is  involved  rather  than  a  four.  Procedurally ,  the  TOE  field 
is  composed  of  a  three  character  Julian  date  (001-365/366)  and  time 
(0000-2359)  but  no  range  tests  need  be  made  (e.g.,  4567890  is 
acceptable  as  a  TOF  field). 

3. 1.9.1.  Check  2. 9. a.  Check  for  seven  numeric  characters. 

Error  Condition  -  Any  non-numeric  character  in  any  of 
the  seven  character  positions  of  this  field. 

Error  Resolution  -  The  message  will  be  rejected  and 
an  "IN'VALID  HEAD'ER"  service  message  automatically  generated  to  the 
input  port/channel. 

NOTE:  The  next  two  fields,  >  ,3.1.10,  .and  3. 1.11  pertain  to  data 
pattern  messages. 

.3.1.10.  Separator .  If  the  message  is  data  pattern  this 
p-aragraph  applies  and  a  space  character  (no  punch)  separator  must 
be  present  following  the  TOF  field.  Use  of  a  space  separator  in 
this  field  on  non-data  pattern  messages  will  result  in  the  message 
being  rejected  and  an  "IN'VALID  HEADER"  service  message  being 
automatically  generated  to  the  input  port/channel. 

73.1.1  .1.  Check  2. 10. a.  Check  for  space  character. 

Error  Condition  -  Any  character  other  than  a  space 
following  the  TOF  field. 

Error  Resolution  -  The  message  is  rejected  and  an 
"IN"'7ALID  HEADER"  service  message  is  automatically  generated  to  the 
input  port/channel. 

73.1.11.  Record  Count  Field.  If  the  message  is  data  pattern, 

fnis  paragraph  applies.  This  field  must  be  a  four  character  Record 


Count  Field.  There  are  no  exceptions.  The  record  count  is 
intended  as  a  further  safeguard  against  lost  data.  The  Record 
Count  field  may  consist  of  the  letters  MTMS,  the  letters  PITS,  or  a 
four  digit  number  in  the  range  0003-0500.  No  other  haracters  are 
permitted  in  a  message  received  from  a  terminal.  If  the  field  is 
numeric,  it  must  be  a  count  of  the  actual  number  of  records  (cards 
or  line  blocks)  in  the  message,  including  the  header  and  trailer. 
Since  this  field  does  not  appear  in  a  single  card  (LMF  ■'f  SC) 
message  (not  valid  in  the  DSSCS  community),  and  a  record  count  of 
two  would  indicate  only  a  header  and  trailer,  the  minimum 
acceptable  record  count  is  0003.  The  maximum  record  count  which 
may  be  specified  in  this  field  is  0500.  A  Record  Count  field  of 
MTMS  indicates  either  that  the  message  originator  wishes  to  forego 
a  record  count  check  (MTMS  also  in  trailer)  or  that  the  true  record 
count  will  appear  in  the  trailer  card.  Messages  with  a  Record 
Count  Field  containing  MTMS  in  both  header  and  trailer  or 
containing  PLTS  in  the  header  may  exceed  the  500  line  block  limit, 
up  to  a  maximum  of  556  line  blocks  (see  End-of-Message  Processing, 
Data  Pattern).  The  record  count  field  is  saved  for  later 
comparison  with  the  record  count  field  in  the  trailer  card  to 
ensure  that  the  record  count  is  correct.  This  is  also  described  in 
detail  under  End-of-Message  processing.  Use  of  the  Record  Count 
field  on  non-data  pattern  messages  will  result  in  the  message  being 
rejected  and  an  "INl/ALID  HEADER"  service  message  being  generated  to 
the  input  port/channel. 

7.3.1.11.1.  Check  2. 11. a.  If  the  field  is  numeric,  the  value  of 
the  field  is  checked. 

Error  Condition  -  A  Record  Count  Field  value  which  is 
less  than  0003  or  higher  than  0500. 

Error  Resolution  -  The  message  is  rejected  and  an 
"ITv'ALID  RECORD  COUNT"  service  message  automatically  generated  to 
the  input  port/channel. 

’■^3.1.11.2.  Check  2.11.b.  A  Record  Count  field  containing  the 
letters  PUTS  or  MTMS. 

Error  Condition  -  Any  alphabetic  characters  other 
than  PLTS  or  MTMS  in  this  field. 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  RECORD  COUNT"  service  is  generated  to  the  input 
port/ channel . 

>3.1.12.  Security  Redundancy  Field  Sentinel.  Following  the 
record  count  field  if  the  message  is  data  pattern  or  following  the 
TOF  field  if  it  is  teletypewriter,  must  be  the  dash  or  hyphen  (ITA2 
uppercase  "A",  card  "11"  punch)  signalling  the  start  of  the 
Security  Redundancy  field. 

';i3. 1.12.1.  Check  2.12.3.  Check  for  security  sentinel. 


Error  Condition  -  Any  character  other  than  the  dash. 


Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  HEADER"  service  message  is  automatically  generated  to  the 
input  port/channel. 

^.3.1.13.  Security  Redundancy  Field.  When  the  message  is  "A" 

SEL  teletypewriter,  the  character  following  the  dash  must  be  a 
downshift  (Sl/LTRS).  Since  there  is  no  record  count  field  in  this 
format,  the  upper  case  of  the  TOF  field  is  continued  through  the 
dash,  then  the  lower  case  is  required  for  the  security  field.  This 
field  must  begin  with  the  letter  "M"  and  be  followed  by  a  valid 
transmission  control  code  which  consists  of  three  alphabetic 
characters.  The  last  three  characters  will  be  used  later  to  check 
against  each  routing  indicator  and  also  against  the  equivalent 
field  in  Format  Line  Four. 

*J. 3. 1.13.1.  Check  2. 13. a.  For  "A"  select  message,  check  for 
downshift  character. 

Error  Condition  -  Absence  of  the  downshift. 

Error  Resolution  -  The  message  is  rejected,  without 
exception,  and  an  "INVALID  HEADER"  service  message  is  automatically 
generated  to  the  input  port/channel. 

7.3.1.13.2.  Check  2.13.b.  Validate  that  the  first  character  in 
this  field  is  the  letter  "M". 

Error  Condition  -  Any  character  other  than  the  letter 


Error  Resolution  -  The  message  is  rejected  and  an 
"I'CvALID  SECURIT'i  FIELD  -  SEC"  service  message  automatically 
generated  to  the  input  port/channel. 

7.3.1.13.3.  Check  2.13.0.  The  last  three  characters  of  the 
Security  Redundancy  field  are  checked  to  see  if  they  constitute  a 
valid  TCC. 

Error  Condition  -  The  three  characters  fail  the 
validation  check  (not  a  valid  TCC). 

Error  Resolution  -  The  message  is  rejected  and  an 
"invalid  SECURITY  FIELD  -  TCC"  service  message  automatically 
generated  to  the  input  port/channel. 

'7.3.1.14.  Start  of  Routing  (SOR)  Field.  Header  validation  then 
proceeds  to  the  SOR  field.  If  the  message  is  "A"  select  this  is  a 
four  character  field,  upshift  (SO/FIGS),  dash,  dash,  downshift 
(Sl/LTRS).  If  other  than  "A"  select,  the  field  is  the 
two-character  field,  dash  dash. 

Error  Condition  -  Any  error  in  this  field,  or 
detection  of  this  field  beyond  the  fifty-fifth  character  position 
of  the  header. 


Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  HEADER"  service  message  automatically  generated  to  the 
input  por t/channel. 

^  .3.2.  Header  Validation/Verification  of  the  Routing  Indicator 
(RI)  Field. 

.3.2.1.  Routing  Indicator  (Rl)  Field.  The  RI  is  the  "address"  of 
a  message.  In  teletypewriter  messages  this  first  character  must 
immediately  follow  the  SOR  field.  In  teletypewriter  messages  ("A" 
or  "H"  SEL)  with  more  than  one  RI ,  each  successive  RI  must  be 
separated  by  either  one  space  or  by  a  valid  End-of-Line  (EOL) 
sequence  consisting  of  two  carriage  return  (CR)  functions  and  one 
line  feed  (LF)  function.  An  Rl  may  not  be  split  by  either  spaces 
or  by  an  EOL  sequence  in  any  instance  (teletypewriter,  card,  or 
data  pattern  messge).  For  multiple  card  and  data  pattern  messages, 
spaces  (no  card  punch)  are  allowed  between  the  SOR  and  the  first 
characLei  of  ihe  first  RI ,  oe tween  Rls,  between  the  last  R.I  in  a 
line  block  (card)  and  the  end-of-line  block,  and  between  the  last 
Rl  and  the  End  of  Routing  (EOR)  sentinnel. 

5. 3. 2. 1.1.  Check  3.1. a.  If  "A”  or  "H"  select,  first  character 

must  immediately  follows  the  SOR  field. 

Error  Condition  -  First  character  not  found 
Immediately  following  the  start-of-routing  field. 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  ROUTING  FIELD"  service  message  automatically  generated  to 
the  input  port/channel. 

^.3. 2. 1.2.  Check  3.1.1.  N'o  ?,I  may  exceed  seven  characters. 

Error  Condition  -  A  routing  indicator  contains  eight 
or  more  characters. 

Error  Resolution  -  The  message  is  rejected  and  an 
"INA'ALID  RO'JTIN'G  FIELD"  service  message  automatically  generated  to 
the  input  port/channel.  N'o  deliveries  are  made  and  there  are  no 
exceptions. 

"3^. 3. 2. 1.3.  Check  3.1.c. .  N'o  presence  of  shift  characters  or 

"lettering  out"  (except  for  the  single  upshift  necessary  before  the 
EOR  in  an  "A"  select  message). 

Error  Condition  -  Shit t- in/ shit t-out  function 
separating  routing  indicators. 

Error  Resolution  -  The  message  is  rejected  and  an 
”IN"/ALID  ROL'TIN'G  FIELD"  service  message  automatically  generated  to 
the  input  port/channel.  No  deliveries  are  made  and  there  are  no 
exceptions . 

5.3. 2. 1.4.  Check  3.1.d.  Presence  of  non-alphabet ic  or 
non-separator  characters  in  this  field. 


Error  Condition  -  Detection  on  a  numeric  character  in 

this  field. 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  ROUTING  FIELD"  service  message  automatically  generated  to 
the  input  port/channel.  No  deliveries  are  made  and  there  are  no 
exceptions. 

7. 3. 2. 1.5.  Check  3.1.e.  Mixture  of  CENSER  and  DSSCS  community 
RIs  on  a  Y  or  R/Y  channel. 

Error  Condition  -  Any  mixed  "R"  and  "Y"  routing 
Indicators  in  this  field  on  a  Y  or  R/Y  channel. 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  ROUTING  FIELD"  service  message  automatically  generated  to 
the  input  port/channel.  No  deliveries  are  made  and  there  are  no 
exceptions. 

^.3. 2. 1.6.  Check  3.1.f.  Check  for  more  than  500  RIs  in  this 

tield. 

Error  Condition  -  501  or  more  RIs  in  this  field. 

Error  Resolution  -  The  message  is  rejected  and  an 
"EXCESSIVE  ROUTING  FIELD"  service  message  automatically  generated 
to  the  input  port/channel.  No  deliveries  are  made  and  there  are  no 
exceptions . 

^.3. 2. 1.7.  Check  3.1.g.  An  Rl  may  not  be  split  by  an 

end-of-line  (EOL)  sequence. 

Error  Condition  -  A  routing  indicator  is  split  by  a 
valid  EOL  (2  CR,  1  LF). 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  ROUTING  FIELD”  service  message  automatically  generated  to 
the  input  port/channel.  No  deliveries  are  made  and  there  are  no 
exceptions. 

7. 3. 2. 1.8.  Check  3.1.h.  For  "A"  or  "H"  SEL,  each  successive  RI 
must  be  separated  by  one  (and  only  one)  space  or  by  a  valid  EOL  (2 
CR,  iLF)  sequence. 

Error  Condition  -  Any  character  other  than  a  single 
space  character  or  a  valid  EOL  (2CR,  ILF)  sequence. 

Error  Resolution  -  The  message  is  rejected  and  a 
"INVALID  ROUTIN'G  FIELD"  service  message  automatically  generated  to 
the  input  port/channel.  No  deliveries  are  made  and  there  are  no 
exceptions. 

7. 3. 2. 2.  End-of-Rout ing  Field.  The  DOI  format  end-of-routing 
(EOR)  consists  of  either  the  three  character  field  upshift 
(SO/FIGS),  period  (.),  downshift  (SI/LTRS)  for  "A"  select  messages 


or  the  one  character  field  of  period  (.)  for  other  selects.  For 
"A"  and  "H"  select,  the  period  must  be  immediately  followed  by  a 
valid  end-of-line  (EOL)  sequence  (2  CR,  1  LF).  For  card  format 
messages  ("D"  select),  the  remainder  of  the  card  following  the  EOR 
must  be  blank.  Any  characters  between  a  card  EOR  and  the  end  of 
the  card  will  cause  message  rejection.  For  magnetic  tape  messages 
("B"  or  "C"  select)  an  end-of-medium  (EM)  character  may  be  used 
immediately  following  the  EOR.  The  EM  character  in  any  other 
position  will  cause  message  rejection. 

7. 3. 2. 2.1.  Check  3.2. a.  Validate  that  there  is  a  valid  EOR. 

Error  Condition  -  Field  contains  other  than  the  three 
valid  characters  for  an  "A"  select,  or  contains  an  invalid  EOR 
sentinnel. 


Error  Resolution  -  The  message  is  rejected  and  an 


input  port/channel 


- _ _  _ 4.U. 
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^.3. 2. 2. 2.  Check  3.2.b.  "D"  select  multiple  card  message  must  not 

have  extraneous  characters  between  EOR  and  end  of  the  card. 


Error  Condition  -  Any  punch  falling  between  the  EOR 
and  the  end  of  the  card  (Col  80). 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  HEADER"  service  message  automatically  generated  to  the 
input  port/channel. 

'j.3.2.2.3.  Check  3.2.C.  Insure  EM  character,  if  used  in  a  "3"  or 
'  C"  select,  is  immediately  following  the  EOR.  If  not  used,  tlie 
remainder  of  the  line  block  must  be  spaced  filled. 

Error  Condition  -  E-l  character  does  not  immediately 
follow  the  EOR  sentinnel. 


Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  HEADER"  service  message  automatically  generated  service  to 
the  input  port/channel. 

T: 

^.3.3.  Header  Validation/Verification  of  the  Security  Line. 

r: 

'  .3.3.1.  Security  Line  (FL4).  Following  the  EOR,  the  next  field 
to  be  validated  verified  on  all  teletype'writer  ("A"  or  "ii"  SEL) 
messages  is  the  security  line,  format  line  four.  For  all  messages, 
the  first  four  characters  following  the  EOR  (original  header  on 
piloted  card  messages)  must  be  the  operating  signal  "ZNT"  followed 
by  a  space.  N'hen  it  has  been  determined  that  FLd  has  been  properly 
employed  and  the  first  four  characters  are  valid,  the  next  check  to 
to  find  the  characters  "MuM"  followed  by  a  valid  TCC.  No  characters 
beyond  the  TCC  are  examined  by  the  I-S/A  A.MPE  for  validation 
purposes . 


•J. 3. 3. 1.1 


Check  4. 3. a.  All  messages  are  checked  for  the 


operating  signal  "ZNY",  a  space  character,  and  the  double  "M" 
followed  Immediately  by  a  three  character  transmission  control  code. 

Error  Condition  -  Any  extraneuous  character  other 
than  "Z^^Y"  followed  immediately  by  the  space  character  in  the  first 
four  character  positions  of  the  security  line. 

Error  Resolution  -  The  message  is  rejected  and  an 
"INVALID  SECURITY  FIELD  -  REJ"  service  message  is  automatically 
generated  to  the  input  port/channel. 

^’.3.3.1.2.  Check  4.3.b.  All  messages  are  checked  for  the  double 
"M"  in  positions  five  and  six  of  the  security  line. 

Error  Condition  -  Any  extraneous  character  other  than 
"MM"  in  the  double  "M"  field  (character  positions  six  and  seven  of 
the  security  line). 

Error  Resolution  -  The  message  will  be  rejected  and 
an  "INVALID  SECURITY  FIELD  -  SEC"  service  message  automatically 
generated  to  the  input  port/channel. 

7.3.3. 1.3.  Check  4.3.b.  The  next  three  characters  are  checked 
to  be  a  valid  TCC. 

Error  Condition  -  The  TCC  characters  are  not  valid. 

Error  Resolution  -  The  message  will  be  rejected  and 
an  "IN'VALID  SECURITY  FIELD  -  TCC"  service  message  automatically 
generated  to  the  input  port/channel. 

Note:  ALPS  processing  in  DOI  formatted  messages  indicated  by  the 

first  letter  of  the  TCC  being  a  "Z".  Ivhen  this  is  the  case  and  the 
TCC  is  valid,  special  processing  is  entered  so  that  no  message  data 
will  be  written  to  the  I-S/A  A.MPE  history  record  past  the  TCC. 

V.3.4.  Routing  Indicator  Processing. 

73. 4.1.  General.  After  processing  of  FL4  has  concluded 
satisfactorily,  Routing  Indicator  (Rl)  processing  begins.  If  a 
message  contains  only  one  RI ,  and  that  RI  is  invalid,  the  message 
will  be  rejected.  If  a  message  is  input  on  a  Y  or  an  R/Y  channel 
and  contains  a  mixture  of  R  and  Y  RIs,  the  message  will  be  rejected 
regardless  of  RI  validity. 

'%3.4.2.  Check  5.1. a.  The  initial  RI  validation  is  to  determine 
whether  the.  RI  is  in  the  I-S/A  iV-IPE's  RI  tables.  All  AUTODIN  RIs 
are  not  included  in  every  I-S/A  ^VlPE's  RI  tables.  Each  I-S/A 
AiMPE's  RI  tables  contain  all  directly  connected  tributaries'  RIs, 
all  other  I-S/A  AMPEs'  RIs,  and  all  Non  Automatic  Relay  Centers' 
(NARCs)  RIs.  A  DSSCS  RI  may  be  from  4  to  7  characters  but  must 
contain  6  or  7  characters  if  addressed  to  an  I-S/A  iVMPE  tributary. 

If  the  RI  is  a  local  I-S/A  A.MPE  tributary,  the  first  six  characters 
are  checked  for  validity  and  determination  of  delivery  destination, 
the  seventh  ignored.  If  the  RI  is  a  distant  1-S/A  AMPE  tributary 


or  a  NARC,  local  or  remote,  only  the  first  four  characters  are 
scanned  for  validity  and  determination  of  delivery  destination. 

If,  during  the  transition  period,  the  first  four  characters 
indicate  a  collective  RI  (YHCR) ,  the  last  two  characters  determine 
the  actual  collective  list  for  delivery  destinations. 

Error  Condition  -  A  routing  indicator  is  not  found  in 

the  RI  tables. 

Error  Resolution  -  If  the  message  contains  only  one 
RI  or  no  valid  RIs,  it  will  be  rejected  and  an  "INVALID  ROUTING 
REPROTECT  TO"  service  message  will  be  automatically  generated  to 
the  originating  station.  If  received  from  another  I-S/A  .AMPE,  the 
message  is  "dumped  and  acked"  (no  message  rejection  instituted)  but 
the  service  message  is  still  generated  to  advise  the  originating 
station  of  the  required  reprotection.  If  the  message  contains  at 
least  one  valid  RI ,  it  will  be  accepted  and  processed  for  delivery 
to  the  valid  RI.  An  "INT/.ALID  ROUTING  REPROTFCT  TO"  service  message 
will  be  automatically  generated  to  the  originating  station  advising 
of  the  invalid  RI(s)  requiring  reprotection. 

'^.j.A.Z.l.  Check  5.1.b.  Once  the  RI  is  found  in  the  RI  tables, 
the  message  TCC  is  checked  against  those  authorized  for  the 
destination  RI.  In  no  case  does  the  ability  to  accept  one  TCC 
imply  acceptance  of  others;  each  TCC  must  be  specifically 
authorized  or  delivery  cannot  be  made. 

Error  Condition  -  TCC  of  the  message  is  greater  than 
the  TCC  authorized  to  be  received  by  the  destination  RI. 

Error  Resolution  -  If  message  contained  only  one  RI , 
or  if  all  RIs  failed  the  security  checK,  the  message  is  rejected 
and  an  "INA/ALID  ROUTING  -  TCC"  service  message  is  automatically 
generated  to  the  originating  station.  Messages  received  from 
remote  I-S/A  AMPEs  will  not  be  rejected,  but  "dumped  and  acked"  and 
the  same  service  message  generated  to  the  originator.  If  the 
message  contained  at  least  one  RI  which  passed  the  TCC  check,  the 
message  will  not  be  rejected  but  will  be  processed  for  delivery  to 
the  RI  passing  the  check.  The  service  message  will  be 
automatically  generated  to  the  originating  station  advising  the 
remaining  RIs  requiring  reprotection. 

^3.4.2.2.  Check  5.1.c.  Each  DSSC5  community  RI  is  checked 
against  the  LMF  of  the  message.  Three  LMFs  indicate  magnetic  tape 
traffic  (BB,  DD,  and  II)  and  these  messages  cannot  be  delivered  to 
a  non-compatible  destination.  In  addition,  three  LMFs  (HC-Cards, 
EA-eight  level  paper  tape,  and  RT-five  level  paper  tape)  indicate 
the  originator's  desire  that  medium  exchange  be  prohibited,  and 
these  also  cannot  be  delivered  to  a  non-compatible  terminal. 

Error  Condition  -  Any  incompatibility  detected  as  a 
result  of  the  above  check. 

Error  Resolution  -  If  the  message  is  addressed  to 
only  one  RI  or  if  all  RIs  fail  the  LMF  check,  the  message  will  be 


rejected  and  an  "INVALID  ROUTING  REPROTECT  -  LMF"  service  message 
will  be  automatically  generated  to  the  originating  station. 

Messages  received  from  remote  I-S/A  AMPEs  will  not  be  rejected,  but 
"dumped  and  acked"  and  the  same  service  message  generated  to  the 
originator.  If  the  message  contained  at  least  one  valid  RI  which 
passed  the  LMF  check,  the  message  will  not  be  rejected  but  will  be 
processed  for  delivery  to  the  RI  passing  the  check.  The  service 
message  will  be  automatically  generated  to  the  originating  station 
advising  the  remaining  RIs  requiring  reprotection. 

•.3. 4. 2. 3.  Check  5.1.d.  If  the  message  contains  a  collective  RI 
(.may  be  received  from  a  directly  connected  ASC  during  the 
transition  period),  the  initial  check  is  to  determine  if  the  CRI  is 
contained  in  the  I-S/A  AMPE's  tables.  DSSCS  CRIs  must  contain  six 
characters  -  the  first  four  being  the  collective  designator  YHCR, 
the  last  two  indicating  the  specific  collective  routing  indicator. 

Error  Condition  -  Use  of  an  invalid  CRI. 

Error  Resolution  -  If  the  CRI  is  not  found  in  the 
I-S/A  AMPE's  CRI  tables  and  the  message  was  only  addressed  to  that 
RI  or  did  not  contain  any  valid  RIs,  the  message  is  rejected  and  an 
"INVALID  ROUTING  REPROTECT  TO"  service  message  is  automatically 
generated  to  the  originating  station.  Messages  received  from 
remote  I-S/A  AMPEs  will  not  be  rejected,  but  "dumped  and  acked"  and 
the  same  service  message  generated  to  the  originator.  If  the 
message  contained  at  least  one  valid  RI  which  passed  this  check, 
the  message  will  not  be  rejected  but  will  be  processed  for  delivery 
to  the  RI  passing  the  check.  The  service  message  will  be 
automatically  generated  to  the  originating  station  advising  the 
remaining  RIs  requiring  reprotection. 

^'.3. 4. 2. 4.  Check  S.l.e.  A  check  is  made  to  determine  if  the 

input  station  is  authorized  to  introduce  a  CRI/CAD. 

Error  Condition  -  Attempted  input  of  a  CRI /CAD  by  a 
port/channel  not  classraarked  for  CRi/CAD  input. 

Error  Resolution  -  The  message  is  rejected  and  an 
"UNAUTHORIZED  USE  OF  CRi/CAD"  service  message  is  automatically 
generated  to  the  input  port/channel. 

RI  Processing  ^?ote:  '»hen  an  RI  is  found  to  be  the  subject  of  some 
CARP  action,  it  is  first  determined  whether  the  message  being 
processed  is  of  a  category  meeting  the  requirements  of  the  CAR? 
action.  If  it  is,  the  destination  RI  specified  by  the  CARP  action 
is  used  instead  of  the  destination  RI  associated  with  the  message 
and  the  message  is  routed  accordingly.  For  TCC ,  UIF,  and  message 
type  checking,  the  destination  RI  associated  with  the  message  is 
always  used  since  the  originator  should  not  be  serviced  when  the 
normal  destination  RI  can  accept  the  message,  wlien  the  normal 
destination  RI  is  unable  to  accept  the  message  being  processed,  the 
RI  is  rejected  as  in  normal  single  RI  processing  with  appropriate 
service  action.  If  the  message  could  be  delivered  to  the  normal 
destination  RI  but  delivery  is  to  be  diverted  to  a  CARP  destination 
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RI  which  is  unable  to  accept  a  message  of  the  type  or  TCC  being 
processed,  the  message  is  accepted  by  input  processing;  output 
processing  will  divert  the  message  to  temporary  storage  until  the 
CARP  action  is  negated  and  the  message  can  be  delivered  normally. 
Collective  Rls  are  not  subject  to  CARP  action  although  CADs  will  be, 

7.5.  End-of  Message  (EQM)  Processing.  Although  header 
processing  terminates  in  the  I-S/A  A.MPE  with  the  end  of  FL4 ,  the 
I-S/A  AMPE  cannot  anticipate  the  point  at  which  the  end  of  message 
will  occur.  Therefore,  a  continual  scan  of  the  message  for  the  end 
of  message  sequence  (EOMS)  is  performed.  The  DOI  narrative  format 
EOM  procedurally  consists  of  two  car-riage  returns,  eight  line 
feeds,  and  the  letters  "XNXN"  but  the  minimum  required  for 
recognition  by  the  I-S/A  AMPE  is  one  line  feed  and  four  N's.  In  a 
multiple  block  data  pattern  message  it  consists  of  the  letters 
"NXITN"  in  columns  77  through  80  of  the  last  line  block/card.  This 
scan  and  others  necessary  for  the  detection  of  significant 
character  sequences  are  described  in  this  section. 

7.5.1.  Straggler  Protection.  A  "straggler"  is  caused  by  a 
message  without  a  start  of  message  sequence  (SOMS)  following  a 
message  without  an  end  of  message  sequence  (EOMS)  on  an 
asynchronous  channel,  or  two  messages  entered  as  one  on  a 
synchronous  channel  and  framed  SOH-ETX  as  a  single  message.  To 
protect  against  straggler  messages,  the  1-S/A  A.MPE  validates  the 
Originating  Station  Serial  Number  (OSSN)  in  the  message  header 
against  the  Trailer  Station  Serial  Number  (TSSN)  found  in  the 
message  trailer.  (See  Section  7  for  CRITIC  exceptions.) 

’?.5.1.1.  Data  Pattern  Messages.  The  EOMS  must  be  the  "N';c,'N" 
sequence  in  columns  77  through  80.  The  EOM  line  block  must  contain 
the  ETX  character  in  the  third  framing  character  (FC3)  and  it  is 
incumbent  on  the  terminal  to  ensure  that  the  EOM  is  properly 
recognized  and  the  block  properly  framed.  Receipt  of  an  ETC 
framing  character  without  a  correct  EOM  results  in  message 
rejection  and  generation  of  an  "INVALID  EOM"  service  message  to  the 
input  port ''channel.  Receipt  of  a  valid  EOM  without  the  ETX  results 
in  non-recognition  of  the  EOMS  and  an  input  message  hiatus 
rejection  of  a  following  SOH  lineblock,  and  the  ultimate  rejection 
of  the  errored  message.  (See  Section  7  for  CRITIC  exceptions.) 

.5.1.1.!.  An  offshoot  of  EOM  processing  is  the  check  for  a 
valid  record  count  field  in  a  multiple  line  block  card  or  magnetic, 
tape  message.  There  is  a  relationship  between  this  field  and  the 
record  count  field  of  the  header.  The  trailer  record  count  field 
must  be  either  "MTMS" ,  signifying  a  message  from  a  magnetic  tape 
terminal  which  does  not  count  line  blocks,  or  a  four  digit  numeric 
field.  The  use  of  "PLTS"  in  the  trailer  is  prohibited  and  will 
result  in  message  rejection  and  an  "IN"7ALID  RECORD  COUNT"  service 
message  being  automatically  generated  to  the  input  port/channel. 

If  "MTMS"  appears  in  the  record  count  field  of  both  the  header  and 
trailer,  no  further  checking  of  the  actual  line  block/card  count  is 
performed.  If  a  number  appeared  in  the  header  and  "MTMS"  or  a 
number  in  the  trailer,  the  actual  line  block/card  count  received  is 
checked  against  the  header  number,  and  the  trailer  record  count 
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field  is  effectively  ignored.  If  "MTMS”  appears  in  the  header 
record  count  field  and  the  trailer  field  contains  a  number,  that 
number  is  compared  to  the  actual  count  of  the  line  blocks/cards 
received.  Any  disparity  in  the  above  two  instances  results  in  the 
message  being  rejected  and  an  "INVALID  RECORD  COUNT”  service 
message  being  automatically  generated  to  the  input  port/channel. 
When  the  message  header  record  count  field  contains  the  pilot 
indicator  "PLTS" ,  there  is  no  check  of  either  the  header  or  trailer 
record  counts  against  the  actual  number  of  blocks  received. 

?  .5.1.2.  Teletypewriter  (Narrative)  Messages.  The  minimum  EOMS 
recognizable  is  one  linefeed  character  and  four  N's  in  an 
uninterrupted  sequence.  More  than  eight  line  feeds,  extraneous 
characters  in  the  linefeed  field,  or  extraneous  characters  between 
the  TSSN  and  the  required  EOMS  are  acceptable  provided  that  the 
straggler  sentinel  (v)  falls  within  23  characters  of  the  required 
line  feed  and  the  lequired  EOMS  is  not  interrupted.  If  the  EOMS 
does  not  fall  within  23  characters  of  the  TSSN,  the  message  will  be 
rejected  and  a  "SUSPECTED  STRAGGLER"  service  message  automatically 
generated  to  the  input  port/channel.  (See  Section  For  CRITIC 
exceptions . ) 


5.5. 1.2.1.  On  asynchronous  channels,  there  is  no  such  thing  as 
an  invalid  EOMS.  If  not  correct,  the  result  will  be  either  an 
input  message  hiatus  or  a  two  consecutive  SOM  condition.  Either 
results  in  message  rejection.  On  synchronous  channels,  detection 
of  the  ETX  framing  character  without  prior  detection  of  a  valid 
EOMS  results  in  message  rejection  and  an  "I'rv'ALID  EOM"  service 
message  automatically  generated  to  the  input  port/channel. 

.5.2.  Cancel  Transmission  Sequence  (CAN'~R;\?»3) .  The  1-5  ■'A 
also  scans  for  the  presence  of  a  CANTRANS  which  procedurally 
consists  of  8  E's  each  separated  by  a  space,  the  letters  "AR",  and 
an  EOM.S  of  two  carriage  returns,  eight  line  feeds,  and  four  \’'s. 

The  minimum  recognizable  by  the  I-S/A  AMPE  is  two  E's  separated  and 
followed  by  a  space,  "AR",  one  linefeed,  and  four  N's.  A  CANTR*\NS 
is  not  recognized  if  it  occurs  prior  to  the  line  feed  character 
that  terminates  message  header  processing  or  following  the 
straggler  sentinel  preceding  a  valid  TSSN.  'Caen  recognized,  t'ae 
message  is  discarded  by  the  I-S/A  .VMPE  with  printout  notification 
to  the  system  console  operator  that  the  message  has  been  discarded. 

5.5.3.  Excessive  Message  Length.  An  additional  check  I'vat  is 
performed  during  receipt  of  message  text  is  a  count  of  total  line 
blocks/characters  being  received.  Should  this  count  exceed  55'i 
line  blocks  (44,480  characters),  the  message  is  rejected  and  an 
"EXCESSIVE  MESSAGE  LENGTH"  service  message  automatically  generated 
to  the  input  port/channel.  Mode  II  (non-Query/Response)  channels 
are  limited  to  125  line  blocks  (10,000  characters).  (See  Section  ;« 
for  CRITIC  exceptions.) 

‘.5.4.  Excessive  Input  Hiatus.  Incoming  messages  are  also 
monitored  for  any  delay  (hiatus)  in  receipt  by  the  I-S/A  (UMPE. 

When  no  additional  data  is  received  for  a  message  in  progress  for  a 
period  of  approximately  three  minutes,  the  message  is  rejected  and 
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a  "MO  EON  RECEIVED"  service  message  aiitonaticall y  generated  to  the 
input  port/Channel.  (See  Section  8  for  CRITir  exceptions.) 

7.5.5.  Framing  Character  (FC)  Processing,  '^raming  characters  are 
validated  for  all  input  messages.  On  asynchronous  channels,  these 
have  been  inserted  and  the  message  blocked  and  framed  by  the  I-S/A 
AHPE  itself  so  that  FC  validation  is  essential!/  a  self-checking 
process  by  the  I-S/A  AMPE.  On  synchronous  channels,  ~C  validation 
serves  to  ensure  proper  framing  by  the  terminal  device.  In 
addition  to  the  channel  control  functions  between  the  Noce  I 
terminal  or  I-S/A  ANPE  and  the  distant  Node  I  terninal  or  I-S/A 
ANPE,  certain  framing  characters  are  used  internally  by  the  I-S/A 
AMPE  to  insure  that  there  is  no  inadvertent  loss,  diiolication  or 
sec  iri  ty  mismatch  of  message  data  within  the  I-S/A  AMPE.  "^his  is 
particularly  true  of  FCA,  which  is  the  Block  Parity  Character  in 
transmission  over  a  channel  but  becomes  a  hlock  sequence  number 
within  the  I-S/A  AMPE,  and  FC?  on  all  but  the  SOH  linehlock,  v/hich 
is  an  ASCII  delete  in  transmission  to/fron  a  terminal,  hut  which  is 
used  within  A'JTODIN  as  a  security  or  ETR  seouence  character.  Any 
^‘raming  character  error  results  in  message  rejection  with  a 
"REPROTECT  TO  ALL  ADDEES"  service  message  being  automatically 
generated  to  the  input  port/channel .  In  add’h^'^n,  s  printout  of 
the  FC  error  is  provided  to  the  system  console  operator  so  that  any 
FC  errors  caused  within  the  I-S/A  AflPE  itself  may  be  detected  and 
corrective  action  taken. 
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7,7.0  DQf-103  -  DS5CS  r-lESSAGE  FCFMAT 

I  Following  is  an  EXAr^PLE  of 


a  DOI-103  formatted 

message  which  shall  be  built  from  a  DD-173  Form  or  an  Ah'F.  The 


1-3  A  AMPE  shall  ve.  liiate  fo-rat  lines  2  thru  15  when  received 
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7,7  2  1  •  “lELE  2NE  is  the 


precedence. 


On  i  4 
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r  iE  a  r  r 
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e  d  in  C  E 
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r  „  n  ,  i  -  * 

?  3  r  i  "  r  ■ 
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- -  ■  f  r  ^  i  f  •  .;i  r. 


15  1  ^  e  1  n  p 

L:‘'r  c''a''scte’' 


or  3 


1  h  e  s  ?  a  Q  e  0  e  1  r'  ' 


car,  0  n  1  'j 
"  d  t  ■  e  LNF  5  Or 

'■  r  •  r-*  r  g  U  r  a  w  0  -t  0  r  1  1 


to  rr 


U.-JCLASSIFIED 


7:7  2  2,  3  '■fi?  LriF '  5  of  “G"  and  "Y"  are  generated 
by  the  1-5/A  AMPE.  Yhs  Lh'F'a  of  “GT“  and  "YT"  indicates  that 
the  1-5.  A  AiYPE  prefer, ned  format  conversion  on  the  message. 


n" 


7j7  2.3  FIELG  FCUR  -  is  the  DSSC5  security  sentinel 


77.2,4.  ,“'EL2S  FIVE  T.FPU  EIGHT  -  is  the  Content 

Indicator  Coda  (CIC>  The  four  character  CIC  field 

false  called  the  c  ommu'^  1  c  a  1 1  on  s  action  identifier  field 

:i(hen  It  contains  c  ommur  1  c  a  1 1  on  5  instructions)  contains 

information  related  to  the  type  O'  message  being  processed  The 
CIC  ‘IS  validatea  to  be  either  four  alphabetic  or  three 
alphabetic  and  one  numeric  c.r aracters. 


message 


5  -FIELD 

r  e  j  e  c  r  a  .p , 


7,7  2.  6  FIELDS  10  THRU  16  is  the  Originating 

Station  Pouting  Indicator  f CSP I ) .  On  DSSCS  messages,  the  QSP I 
must  start  uith  the  letter  -'V"  and  are  si*  characters  long. 

He li' ever,  a  seventh  character  may  be  added  to  indicate  certain 
communication  center  fu-’cticns.  Ail  characters  must  be 
aipj-'.abetic,  or  the  message  is  rejected  it  a  si'(  c,haracter 
05 PI  is  used,  then  the  se'-enth  position  must  be  a  space,  or  the 
mi  e  s  3  .0  g  e  la  1 1  i  be  r  e  j  e  c  t  e  d  , 

7i7  m  7  ,~IELDS  17  THRU  20  is  th.e  ‘Station  Serial 

Mumber  f  SS.V)  I*  tne  station  is  operating  in  the  ITA-2  code, 

then  t'e  SEN  must  be  preceded  by  a  figure  (upper  case)  function 
"he  55N  m.ust  be  all  -..icers  or  the  .message  is  rejected.  The 

55‘-  a  1  s  :•  is  used  as  t'e  E'-d  f  .'^cssage  EON)  validation  number  in 


15  3  3p3C3'  IT  uTi®  15 

TH.mU  25  -  IS  the  i  me- o  f -F  i  1  e 


rv  .^*v‘.  vj 


r.-. 


I 


u 


h: 


UNCLASSIFIED 


7»7  .  2.  10“  FIELD  2?  -  1-3  a  dash  (-)  <lJ^ich  indicates  the 
start  of  the  securitu  field.  If  not  present/  the  message  uill  be 


rejected. 


. 

7  7 

■  7,  2 

.  1 1,.  FIELD 

£  3C  THRU  33  -  1 

s  the 

security  field. 

Pos  1 

1 1  on 

30 

must  be 

the  DSSCS  security  s 

entinel  of  "M",  or 

-*■ 

tn  e 

<  n  5  3  3  .3 

ge 

13  rejecte 

d  0  5  1 1 1  0  n  31 

thro 

ugh  33  IS  the 

G 

Tran 

3  iTl  1  S  3  i 

0  n 

Control  C  -o 

d  e  X  t  C  L  ) .  1  h  e 

TCC 

IS  derived  f  r  om 

1  r,  -  Q 

r  ,r  a  1 1  c 

n  CO 

ntaii:ed  in 

mess-age  format 

line 

12,  that  is  the 

K 

c  1  a  3 

Sirica 

t  i  0  n 

,  codeword 

<  eax-eats,  and 

other 

data  appearing  in 

r.-. 

~  e  s  3 

age  Fo 

r  na  t 

Line  12,  N 

essages  are  reje 

c  t  e  d  1 

^  tne  TCC  is  not 

[•  - 

1  r. 

a  c  c  0  r  c 

s.  nee 

w ;  t  h  data 

in  Format  Line  1 

2  or  1 

f  it  is  an  i nva lid 

1  n 


^  "z 

'  2.  11  1  The  I-S/A  AITPE  must  validate  that  the 

message  ’^ormat  lines  2  and  -i  are  valid  according  to 
1  n  -  ■0*' "  a  1 1  ;  n  •:  ■:  n  t  a  :  ••  e  d  in  message  format  line  12.  Anu  error  uill 
result  in  the  message  being  ■^ejected 

7.7  2  12  FIELD-2  34  AND  35  -  are  2  dashes  ( —  1.  which 
iroicates  the  start  of  routing  Ang  invalid  character  or  less 
than  two  dashes  will  result  in  the  message  being  rejected 

7;7  2.  13,  FIELD'  32  -  is  the  start  o-^  routing  .All  D2SCS 

SI  3  must  start  iJith  the  letter  "Y".  or  the  message  is  rejected. 
DSEC2  FI's  are  six  letters,  but  there  can  be  a  seventh  letter. 
■£ac-'  ~I  is  S5?  a  rated  bg  a  space,  or  the  message  is  rejected,  f 


n  1  X  1  m  u  m  o  *  4  FI 

r 


I  i  i  A  p  p  c*  B 1 


ejected.  A 

on  the  ^irst  line  of  Format  Line 

With  a  .na<im'jn  of  routing  indicators  on  each 

successi^'e  line,  A  maiiirum  of  5C0  RI's  are  authorized  on  a 
DEE '2  re  Si  age  I-  a  rasrS'ge  e.tceeds  cOO  Pi's,  the  -messag 
15  '  e  j  e  •:  t  e  0  The  .m  e  i  a  g  e  will  be  r  e  j  e  •:  t  ?  d  if  FI  s  are  s  p  1  i 

across  a  line.  =■.  s'  as  tbe  -i~st  3  r'a'acter  on  one  lire  then 

a  n  0  s  -  1  1  -  e  -  u  'i  c  t  i  o  "  s  1  1  :  w  a  i  b  g  t  r  e  r  m  a  i  n  o  a  r  of  t  h  .?  -  I  I  -  any 

"  0  u  1 1  *1  g  1 1",  'j  1  c  a  t  c  T'  w  i  g  i  s  1 1  h  any  c  ~i  a  i*’  a  i  c  e ' '  other  t  n  e  n  a  , ,  the 

■entire  message  must  o  e  '.'ej-'Steo  and  ncra  .or  the  re, raining  or 

V  a  1  1  c  routing  :  n  d  ;  :  a  s  o  r  s  a  r  o  o  o  c  e  s  s  e  -d .  A  period  ( ,  )  will 

illowi'g  the  last  addressee's  F;  to  indicate  end- 

the  T  -D  C  level 
:  0  r  ■:•  c  e  i  V  e  the 


;  e  inserted 

■  o  -  -  0  u  t :  r,  g 

;c  ensure  oh 

■  e  s  s  a  g  s 


ct  (D 


i:ii.».ii.F.iyj  ,  I.  .■!  ^^v"'  rP,'  ,"J  ,";-^V  "*  "-^r-' 


Ur^CLASSIFIED 


^  3,  F^RriAT  LIUE  4.  SECURITY  LINE 

77  3  1  The  first  three  characters  are  the 
security  uiarning  operating  signal.  On  DSSCS  messages  this 
will  always  be  "2NY"<  including  unclassified  and  unclassified 
EFTO  messages.  Following  the  security  warning  operationg 
signal/  there  must  be  a  space  character/  or  the  message  is 
rejected.  Following  the  space  is  the  CSSCG  security  sentinel 
"TiN"/  any  other  characters  or  only  one  'Tl"  will  result  in  the 
message  being  rejected.  Following  the  "''’fT'  is  the  DS3CS 
T^'ansmission  Control  Code  (TCC).  The  TCCs  in  Format  Line  2  and  4 


.7)  U  3  t 

match/  0 

■p  i-  u 

e  .Cl  e  3  3  a 

g  e  is  r  e  j 

acted.  A  d  d  1 1  i  0 

naly,  the  I-S/A 

AMPE 

shall  V  9 

rify 

that 

the  TCC 

IS  a 

V  a  1  id 

TCC  authorized 

for 

the  input 

1  I 

n  9  Th 

e  I-S/A 

AriPE  s 

nail 

also  verify  the 

cons 

istency  of 

Format  L 

1  nes  2 

and 

4  sec 

urity  paramters 

against  the  securit 

y  data 

contained 

in  Format  Line  12.  Any  error 

or  mismatch  of 

TCC  ' 

s  will 

c  a  u  s  e  the 

n  e  s  s  a  g  e 

to  be 

rejected 

7  7  A 

FCF.riAT  LIN 

E  4A,  DIRECTOR  LI 

NE 

7^- 

li 

The 

start  of 

f  0  r  iTi  a  t 

line 

Aa  is  the 

pr  oc 

ess ing  in 

d  i  c  a 

^  T*  “7 

KZK".  A 

space  function 

must  follow  the 

star 

t  of  line  p 

r  0  c  e 

•5  s  i  m  g  1 
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The  n  e  >. 

t  two 

characters  are 

t  n  e 
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p  r  e  c 

e  d  e  n  c  ? 

of  the 
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On 

dual  precedence 

mess 
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1  be 

the  action  p-ec 
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If  any  two 
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f  line  imdicator 

0  f 

'Dc"  E-ro 

1; 

in  For 

m  at  Lire 

AA  - 1  : 

1  ~  0  t 

’■“■suit  in  the 

.T  s  3 

a.g  e  0  e  ing  r 

.*»  1  a  1” 

-  J  •  - 

to:.  0  . 

t  e  V  e  r  t  V 

d  t  a 

1  :  ;  a  i 

0  a  1  1 1  0  “  at  the 

cell 

.  ?-y  I-E  ’A 

A-  =  E 

T  2~  :  - 

3“-'“  lCr'’> 

^  ^  ^  r  ^ 

t 

^  1  e  1  ~  rj  A 
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UNCLASSIFIED 


7»7j  5  The  First  character  is  the  precedence  of  the 

message  (See  paragraph  1.1  for  valid  precedence  characters 
in  the  DSSCS  community  and  DC  I- 103  Format)  In  case  of  dual 
precedences/  the  action  precedence  is  first/  folio 'a  ed  by  a 
space  function  and  the  information  precedence/  followed  by  a 
space  function.  (see  paragraph  3.6  1.  for  t  r  a  niO  i  s  s  i  o  n  s  w.hen 
the  action  precedence  is  FLASH  and  the  inf  or ma  tion  precedence 
is  iriHEDIATE  or  lower)  Following  the  space  is  the  D"^G/ 
which  consist  of  6  numbers  and  the  Greenwich  Zone  suffix  (2) 


7*7  r  5  2  Following  the  DTO/  and  preceded  by 
function/  is  the  abbreviated  month/  followed  by 
function  and  the  last  two  digits  of  the  year 


space 


7,7.5  3  Following  the  year/  preceded  by  a  space 
function/  can  be  special  operating  signals  vZ  or  Q  Signals  lAU) 
DGI-l.j3  or  ACP-iSl).  131)  Cn  all  DSSCS  messages  of  I.HHEDIATE 
precedence  o"  higher,  the  operating  signal  of  ’’ZYH"  must  appear 
on  the  message  If  /more  then  one  operating  signal  is  required 


precedence  ( 
on  the  m e  s  s a : 


message/ 


each  IS  separated  by  a  space  function. 

5.3.  I.-'  Certain  phrases  in  message  format  line  12 
the  placing  of  a  ’G"  or  "Z"  signal  in  format  line 


=  FG.‘^;(Ar  LIFE  6  -  HESS, AGE  CRIGIfJATDR 

7,7.  i)  1.  The  fi-st  two  characters  is  the  prosign 
"FH".  following  the  pro  sign  is  a  space,  and  the  PLA  of 

the  activity  which  originated  the  message.  The  PL.A  must  be  valid 
m  accordance  with  DSSCS  e  s  s  i  n  g  documents. 


Product 


“  c  1  i  G  'xj  1  r.  'j  z ' 
Z- 1  5 1 7  1  b  u  T, :  c  n 
:  €  -ji  ? 


“‘.cr  T'-c 


jraC‘:er=.  ar-? 
s  p  2  ;  a  n  b 


z  p  *  *  -  .'5  n  ' 


tb2 

■Che  PLAi 

valid  in 


UNCLASSIFIED 


7,7  8.  Format  Line  S  -  INFORMATION  ADDRESSEE(S)  OF  THE 

MESSAGE. 

7.7.  .8.1.  The  first  4  characters  are  the  prosign 
"INFO".  Following  the  prosign  is  a  space,  and  the  PLAfs).  DAG's. 
or  PD.  The  address  must  be  valid  in  accordance  with  DSSCS 
addressing  documents 


rURMAT  LiNE  9  is 

not 

used 

in  DSSCS. 

7,7  10. 

FORMAT  LI.NE  10  - 

i  5 

not  no 

rmally  used  on 

DSSCS 

n  e  5  3  sO  g  e  s  .  uni 

ess  the  message 

i  3 

a  f 

ive  letter/nuiTiber 

coded 

message.  If  used,  format  line  10 
by  tne  I-S/A  AMPE 

i  5 

not  re 

guired  to  be  val 

i da  ted 

7.7,  11.  Format  Line  11  -  START  OF  TEXT  INDICATOR. 

7.7.  11.  1.  The  start  of  text  indicator  in  the  DSSCS 
community  is  "ZEM".  and  must  appear  on  all  messages.  or 
t.he  message  is  rejected. 

7,7  12  or  mat  Line  12,  Text  of  the  message 

7,7.  12.  1  For.rat  line  12  consist  0^  several  specific 
which  must  be  in  the  proper  seo.uence  for  correct 


items 
validation 


7,7.  1; 


CLASSIFICATIC  "J. 


7, 7  12.2.1.  Unciassif  ed  is  abb’'e\iated 

witr,  out  soacing  between  the  lette  s. 


"UNCLAS" 


7,  7 1 2  2.2.  Un  1  a  s  5  1  f  i  ?  d 

d"  e  n  m  1  s  •  2  n  Only  is  s  b  2  r  e  v  1  a  t  e  d  as 

wio'ojt  spacing,  -oilowe.  b a  space  and  E 
3920  - -a  ted  by  a  space. 


=.  n  c  r  y  2  t  2  J 
'UrJCu-AS  S  “  ■  0" 

■  “  ~  2,  I  t  h  esc: 


7..7  12.  2.  3 

tie  classificat 
D  ENT  I  A  L 


:r;er  classificat 
must  be  separated 


c  .  \-  0 


0  r 

N  F  I 


1  cn 


space. 


1  ,  .  V  ■  u  ■  V_"  V  T'"  •  11  «  |ia  • 


UNCLASSIFIED 
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N 
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^  -  • 
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»f 

r 

f-.  ■ 
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7«7-  12,  2,  4'  Any  special  handling  instructions* 
codewords*  or  caveats  that  follow  the  classification  shall 
be  separated  from  the  classification  by  two  spaces  and  also 


separated 

from  each  ot 

her 

by  two  spaces.  In 

the  c las  5 i f 1  cat  1  on 

line*  words 

shall  not  be 

hyphenated  and 

continued  into  the 

next 

line  Each 

line  shall 

^  r 

d  with  a  completed 

word.  Caveats 

will 

be  broken  a 

t  a  space  but 

n  c 

t  hyphenated 

at  the 

end  of  the  line  or 

with  a  Si 

ant.  The  TCC 

1  n 

format  lines 

2  and 

4  are  derived 

from 

1 n  f  0  r  ma  1 1 c  n 

cn  this  line 

7,7  12  2  5. 

Cn 

a  separate 

line 

following 

the 

classificat 

ion*  special 

handling  instructi 

on*  etc.*  i 

s  the 

2S5CS  delimeter  of  4  Q's 

7,7  .  12.  2,  6 

On 

a  separate 

line 

following  th 

e  4 

Q  '  s 


1  3 


:he  transmission  sectional  data. 


7,712.  2.  7.  Gn  a  separat' 
sectional  data  (if  applicable)  i' 
number  (if  used) 


line  following  the 
the  message  reference 


separate  line  is  the  internal 


7,7  12  2  a.  Cn 

handling  or  command  passing  instructions,  if  used.  (Exercise 
name  o"  orcject  name,  if  used). 


t  ai 


7,7  12  2  a  ajb;ect  line 
h  the  letters  ''£U2J". 


This  line 


w  1 


a  1  wau  s 


a  subject  is  not  supplied 


by  the  o-iginstor  the  I-E/A  must  insert  thi' 

will  contain  t.he  lette-s  S^joJ". 


line* 


which 


d.("‘ 
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7  7 


al:da"i.pn  o*  for. mat  line  12  by  the  I-S/'A 


lire  1C. 
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e  '  0  ~  e  s  5  e  d  by  t  n  e 


7.7  12 


1-1  a“e  not  used  in  CSGCS. 
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has 
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separate 
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ecessarij  corrections  ) 
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8.0. 


CRITIC  Format  Message  Processing  Requirements. 


8.1.  General  Connents.  CRITIC  nessages  are  unique  to  the  DSSCS 
comum' ty  and  are  to  be  afforded  special  processing  throughout  the 
systen  to  ensure  the  nost  expeditious  handling  possible.  They  are 
recognized  by  detection  of  a  CRITIC  prosign  which  consists  of  a 
nine-character  field  "UU  YEKAAH"  in  the  header  position.  The  I-S/A 
Af'lPEs  nust  recognize  this  field  and  allow  its  use  on  any  DSSCS  (Y) 
port/channel  or  DSSCS/GENSER  (R/Y)  port/channel  regardless  of  the 
normal  format  used  by  that  port/channel. 

8.2.  Validation/Verification  Requirements 


8.2.1.  Format  Line  1  -Transmission  Identifier  (TI)  Line.  I-S/A 
AflPE  validation  of  the  TI  line  is  identical  for  both  asynchronous 
(Mode  II  and  V  teletypewriter  terminals  whose  use  of  a  TI  line  is 
mandatory)  and  synchronous  (Mode  I  users  who  employ  line  block 
framing  and  whose  use  of  a  TI  line  is  optional  but  must  be 
specified  at  the  time  the  I-S/A  AMPE  sets  the  port/channel 
parameters)  channels.  All  TI  lines  through  the  CD-CSN  fields  are 
processed  as  follows; 

8. 2. 1.1.  The  first  characters  of  the  TI  line  block  must  he  a  Start 
of  Header  (SOH)  and  a  select  (SEL)  character.  If  the  channel  is 
asynchronous,  these  have  been  inserted  by  the  I-S/A  AflPE;  if  the 
channel  is  synchronous,  the  terminal  has  inserted  them. 

8. 2. 1.2.  Check  1 >1 The  first  data  character  of  the  TI  line 
must  be  the  1 etter  "C" .  (If  the  channel  is  asynchronous,  the  "ZCZ" 
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portion  of  the  Start  of  Message  Sequence  (SOMS)  was  previously 
validated  and  then  discarded  by  the  1-S/A  AMPE.) 

Error  Condition  -  N'one  -  nothing  can  be  recognized  prior 
to  receipt  of  the  SOH. 

Error  Resolution  -  N’/A 

®.2.1.3.  Check  l.l»b»  The  second,  third  and  fourth  characters  of 
the  TI  line  must  be  the  Channel  Designator  (CD)  and  must  match  the 
CD  stored  at  the  I-S/A  AMPE  for  that  port /channel . 

Error  Condition  -  A  CD  is  considered  to  be  in  error  if  it 
does  not  match  the  CD  stored  in  the  I-S/A  AMPE  for  its'  associated 
channel. 

Error  Resolution  -  CRITIC  messages  will  be  accepted  and  a 
service  message  automatically  generated  to  the  input  port/channel 
advising  of  the  error  and  of  message  acceptance. 

^.2.1.4.  Check  l.l.c.  The  fifth  character  of  the  TI  line  can  be 
either  a  figures  shift  or  the  first  character  of  the  CSN  field;  the 
figures  shift  must  be  present  for  "A"  Select  (ITA  2)  messages  and 
may  or  may  not  be  present  for  other  selects.  Mote  that  for  all 
processing  purposes,  "A"  Select  CSM's  are  always  assumed  to  begin 
in  the  sixth  position  of  the  TI  line.  This  is  done  so  that  the 
"CSN"  to  be  quoted  back  to  the  terminal  in  a  service  message  will 
be  positionally  correct  even  if  the  figure  shift  is  garbled, 
leaving  the  CSN  field  in  the  lower  case.  If  the  CSN  is  correct,  TI 
line  processing  is  complete  at  this  point. 

Error  Condition  -  A  CSN  is  considered  to  be  in  error  if  it 
is  either  non-numeric  or  if  it  is  not  the  next  expected  CSN  (i.e., 
one  greater  than  the  last  accepted  from  a  Mode  V  port/channel  or 
received  from  a  Mode  I  or  II  port/channel.  For  this  purpose,  a  CSN 
of  000  is  considered  to  be  one  greater  than  990, 

Error  Resolution  -  CRITIC  messages  will  be  accepted  and  a 
service  message  automatically  generated  to  the  input  port/channel 
advising  of  the  error  and  of  message  acceptance. 

8. 2. 1.5.  Further  I-S/A  AMPE  TI  Line  processing.  In  order  to 
maintain  CSN'  continuity  between  the  I-S/A  A>'?E  and  the  terminal, 
the  I-S/A  A.MPE  tables  are  updated  based  on  the  results  of  CSN'  and 
message  processing.  ’Nhen  a  CSN  is  rejected  (i.e.,  duplicate 
condition),  no  CSN  updating  is  performed. 

'when  a  CSN'  is  accepted,  even  if  it  is  out  of  sequence,  the 
accepted  CSN  (or  the  expected  CSN,  if  the  received  CSN  is 
non-numeric)  is  made  the  last  accepted  CSN  for  processing  of  future 
messages,  vvhen  the  channel  is  Mode  I  or  Mode  TT  this  update  Is 
done,  immediately  on  receipt  of  the  TI  line  whether  the  associated 
message  is  accepted  or  not,  since  the  Mode  I  or  Mode  II  terminal  is 
assumed  to  update  the  CSN'  at  the  beginning  of  each  message 
transmission.  This  is  also  consistent  with  a  terminal  transmitting 


a  t-ape  in  which  there  are  pre-cut  CSN's  preceding  each  message. 
Since  Mode  V  procedures  require  that  CSN's  be  updated  on  acceptance 
or  the  message,  Mode  V  terminal  equipment  does  not  update  its  TI 
generator  until  the  associated  message  has  been  acknowledged  by  the 
I-S/A  AMPE.  Consequently,  the  I-S/A  AMPE  also  does  not  update  the 
last  accepted  CSN  on  a  Mode  V  channel  until  the  message  has  been 
validated  and  accepted,  and  the  ACK  for  the  message  has  been  sent 
to  the  terminal. 

^3.  Format  Line  2  -  Message  Header.  For  I-S/A  AMPE  validation 

purposes,  the  CRITIC  header  consists  of  one  nine-character  field  - 
the  CRITIC  prosign  field. 

.3.1.  CRITIC  Prosign  Field  Validation/Verification.  The  CRITIC 
prosign  field  is  the  CRITIC  precedence  prosign  repeated  twice  (\vW) , 
one  space  character,  and  the  CRITIC  routing  indicator  YEKAAH.  It 
is  validated  as  a  single  entity  and  no  other  header  or  RI 
validation  is  performed  after  detection  of  the  CRITIC  prosign.  If 
either  one  of  the  precedence  prosigns  is  in  error,  but  the 
remainder  of  the  field  is  correct,  the  non-'’W'’  will  be  corrected 
and  the  message  forwarded  as  a  CRITIC. 

0.3. 1.1.  Check  2.1. a.  The  CRITIC  prosign  field  is  validated  to  be 
vvV  YEKAAH". 

Error  Conditions: 

Use  of  the  CRITIC  precedence  prosign  "W"  in  a  JA.NAP  format  header 
on  either  a  OSSCS  or  GENSER  port/channel. 

Error  Resolution  -  The  message  will  be  rejected  and  an 
immediate  precedence  "IN^/ALID  HEADER  -  REJECT"  service  message 
automatically  generated  to  the  input  port/channel. 

No  space  character  separating  the  CRITIC  precedence  prosigns  from 
the  CRITIC  RI. 

Error  Resolution  -  Regardless  if  entered  on  a  DSSCS  or 
GEN'SER  port/^channel ,  the  message  will  be  rejected  and  an  "INh/ALID 
HEADER  -  REJECT"  service  message  automatically  generated  to  the 
input  port/channel.  If  the  input  port/channel  is  classmarked  as  a 
"Y"  or  an  "R/Y"  circuit,  the  service  message  is  at  the  flash 
precedence.  If  the  input  port/channel  is  classmarked  as  a  "R" 
circuit,  tne  service  message  is  given  immediate  precedence. 

CRITIC  prosign  received  as  "ZN  YEKAAH"  on  a  "Y’"  or  "R/Y" 
port/channel. 

Error  Resolution  -  The  message  is  accepted,  the  "Z" 
changed  to  a  "W" ,  and  the  message  forwarded  as  a  CRITIC. 

Message  recieved  from  a  "Y"  or  "R/Y"  port/channel  as  "WW  YFXAAH 
RUEOCSA  R'JVTCSA." 

Error  Resolution  -  Since  only  the  first  nine  characters 


»C-  . 


constitute  the  CRITIC  prosign,  this  message  would  be  accepted  and 
processed  as  a  CRITIC. 

8.3.2.  Header  Validation/Verification  of  the  RI  Field.  There  is 
no  header  validation  of  any  kind  performed  on  a  CRITIC  message  by 
the  I-S/A  AMPE  beyond  the  nine  character  CRITIC  prosign. 

.3.3.  Header  Validation/Verification  of  the  Security  Line. 

There  are  no  checks  of  any  kind  for  TCC  presence  or  validity. 

5-4.  End-of-Message  Processing.  CRITIC  messages  undergo  normal 

EOM  processing  but  are  not  subject  to  straggler  checks.  Absence  of 
an  End-of-Message  Sequence  (EOMS)  in  a  CRITIC  being  received  on  an 
asynchronous  channel  results  in  truncation  for  either  input  hiatus 
or  for  two  consecutive  Start-of-Message  Sequences  (SOMS),  depending 
on  whether  a  message  with  a  valid  SOMS  follows.  Absense  of  an  EOMS 
in  a  Mode  I  channel  CRITIC  having  a  proper  ETX  framing  character 
results  in  the  ETX  framing  character  being  changed  to  an  ETB  and  a 
truncation  sequence  with  a  valid  EOMS  being  appended  to  the 
message.  The  message  is  accepted  for  delivery  but  is  acknowledged 
as  a  partial  CRITIC  message. 

^•^,8  .4.1.  Cancel  Transmission  Sequence  CCANTRANS).  There  is  a  check 
made  for  a  CANTRANS,  and  a  CRITIC  message  may  be  cancelled  by  the 
input  terminal  using  the  CANTRANS  procedure.  If  CANTRANS  is 
present,  the  I-S/A  AMPE  will  discard  the  message.  It  will  not  be 
truncated  and  forwarded. 

^.4.2.  Framing  Character  Validation.  CRITIC  messages  are  subject 
to  normal  framing  character  validation  and  any  error  will  result  in 
message  rejection  and  a  "REPROTECT  TO  ALL  ADDEES"  service  message 
automatically  generated  to  the  input  port/channel  at  flash 
precedence . 


L'NCLASS  I F I  ED 


FORMAT  LINE  5  W  0122452  JAN  B3  lYHC'^ 

FORMAT  LINE  6  FM  DR  I G INATOR T .> 

FORMAT  LINE' 7  TO  DIRNSAL<= 

FORMAT  LINE  11  ZEM<;"-> 

“CRMAT  LINE  12  CLASSIFICATION  AND  TEXT  ;''  = 
FORMAT  LINE  15  4A'Q9=> 

FORMAT  Lir^E  16  .:======  ==^r INN 


8,5  'ollcuing  paragraphs  uili  shou  uhat  is 

reauired  to  b?  in  a  CRITIC  fressage  -ornattad  bg  the  I-S/A  AMPE. 


8,5  - 


o  r  :r  a  t  -in 


85  ^  'tTha  "outing  line  consists  of  the 

reoeated  CRITIC  p'rece  dance  prosign  "UW"  and  the  CSSCS 
Routing  Indicator  o^  ” > E^ aah" .  The  I-S/A  AMPE  uill  proc-^s  a 
■nessaga  as  a  CRITIC  if  only  one  of  the  tujo  precedence 
characters  is  a  "U"  and  the  other  character  is  an  a  1  p  ha -'nui-ner  i  c 
in  character  position  one  or  t'jo<  as  long  as  the  re;Tiaindar 
(character  positions  3  ch-u  ?)  of  format  line  2  meets  the 
c-ite-'ia  of  space  and  DIRNEA  routing  indicator  YEKAAH.  The 
I-S/A  AI'’PE  uill  charge  the  non  CRITIC  precedence  character  to 
a  "IN'  prior  to  trannisssion 


fl  «.Y 


8,5  2  2.  I?  ang  other  routi-'g  indicator  on  a 
CRITIC  message  -ollcus  '■•E-^AAI-i,  the  "Cuti  ng  indicator  is  not 
valioated,  and  is  alicu/et  to  stag  on  the  message  during 
t  r  a  n  s  m  1  ;  s  1  0  n 


8  5  Forma 

5:5  ,  , 


A  1  'h  1  -0-rat  line  ccr,  toms  the  p  resign  "DE". 
state.  n  e  C  r  i  i  r  e  t  :  ~  -  Z  a  1 1  o  n  Routing  m  :  i  :  a  t  o  ^  ’  0  SR  I  )  .  the 

Station  Serial  Mu  r:  er  p  -  c  e  d  e  ■;  hg  m  ma-k  (  =  ', 

-ollo.je.'S  tg  a  space  chj' aster  a-d  tne  Ti--^.  -  o  -  i  1  o  (TCF/  of  the 
-^essase  All  CRI'^IC  s  uill  ha-e  the  Sf-  o- 


■  •  j  =  -  -i  ■ 


t.-e 


'.-O  v"  0-0  o 


ir  Cl.  -  lb  o  Ci  a 


UNCLASSIFIED 


oiTiiTiur.  1 1  y  sentinel 
ontrol  Cede  (TCC). 
lassification;  co* 
loiays  be  "GAD". 

8-5a  For, 


z.aCk  i.jui 


/’'’Ti". 

Following  the  " 

!TM"  IS  the  Tranmis 

rail 

CRITIC  messages 

/  regardless  of 

or  d , 

etc./  in  Forma 

t  Line  12  the  TCC 

line 

A 

r  .m  a  t 

Line  J-A  on  all 

CRITIC  messages 

5  e  e  p 

anagraph  2.  16.  5 

for  explanation  of 

tr  1  5 

Format  Line 

roT/Tiat  L.ine  3. 


5,57.1  This  line  contains  the  CRITIC 
r  o  5  1  a  r.  "L "  ,  f  o  1  1  o  u  e  d  by  a  space/  and  the 

rou?  fDTG)  of  the  messaoe/  the  abbreviated  month  and  year 
he  hi^h  p-e cede nee  coerating  signal  "7vh" 

8,5  3.  Format  Li~e  6 


=  LA 


8.5  3  1.  .^resign  "rll"  followed  by  a  space 

tne  originating  station 


and 


CR I'lC 

D  I  rz  S  A 


8.5  ^ 

f,5  ? 
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rOTiTlav  L-in*  / 
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■.C‘  and  the  addressee  of 
messages  a  -  e  always  single  a  d  d  r  e  s  s  e  •: 
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Q.  CD 


UNCLASSIFIED 


8|5  12.  Format  Lire  15. 

?|5  12  1.  Thia  lire  conaiats  of  the  End  Of  Message 
validatiOHi  which  is  the  repeat  of  the  SSN  in  format  line  3  of 
the  message  heading.  It  will  always  be  "it9999"  on  CRITIC 
messages. 

S.5  12  Format  Lire  !&. 

8,5  12.  1.  End  of  flessage  Fi;nction 

fig  13.  l.'l  The  EDM  for  a  CRITIC  message  is  the  same 

as  any  other  message/  that  is  2  carriage  returns/  8  line 
■f^eeds/  and  4  N's,  The  I-S/A  AMPE  shall  accept  a  minimum  of  2 

line  feeos  and  4  N's  as  an  valid  EDM. 

CR ITIC  MESSAGE  INPUT  VIA  CARDS, 

8,B  1-  CRITIC  messages  can  be  sent  to  an  I-S/A  AMPE 
using  card  format. 

8,6.  1.1.  If  a  CRITIC  message  is  sent  in  card  format/ 
the  delivery  I-S/A  AMPE  will  convert  the  message  from 

card  format  to  applicable  code  prior  to  delivery/  as  required. 

8,6  -  1-2.  Any  error  in  cards  3  thru  nert  to  last  card 
or  missing  cards  will  not  delay  or  stop  the  processing  of  a 
CRITIC  message  from  a  te-minal. 

8,6  2.  Following  is  an  example  of  a  CRITIC  message  in 

card  format  -rom  a  terminal. 


C  A  R  D  2 


L'N  VEf  .-^AH 
D  E  V  ■'  C  E  R  I  99  999 


CARD  4 
CARD  5 
CARD  o 
CARD  7 

Card  s 

CARD  9 


ZNY  MMG.'-D 

Z  Y  Z K  UN  Z  Z  Z  D E 

ZYH 

FM  CP  I  ZINA tor 
TO  DIPNEA 


F  I  C  A  T 


G  M  AMD  TE,\'T 


LAST  CARD  #9999  NNNN 

8,S  2  1  '  The  last  card  must  contain  only  the  EOM 

validation  number  (#99991  in  columns  1  thru  5  and  the  EOfl  (NNNN) 
in  columns  79  thru  30  No  other  data  can  be  included  in  this 
card  Cards  2  thru  9  and  the  last  card  may  be  pre-punched  and 
be  available  ujhen  needed 

8,6.  3.  The  data  of  each  format  line  is  the  same  as  in 
paragraphs  3.5  .3,  tnrough  8.5.  12 


8,7.C''  CRITIC  MESSAGE  USING  THE  ABBREVIATED  MESSAGE  FORMAT 

( AMF) . 

,  8, 7.1.  CRITIC  messages  can  be  sent  to  the  I-S/A  AMPE  in 
the  AMF  This  requires  the  I-S/A  AMPE  to  build  the  CRITIC 
message  in  accordance  with  paragraphs  8.5.3  through  8.5.13. 

2  The  AMF  contains  fields  which  are  required  and 
fields  that  are  optional  If  the  optional  fields  (Format  Lines 
Aa  and  5)  are  not  present,  the  I-S/A  AMPE  shall  build  the 
“squired  format  lines. 

2  1.  Any  error  in  f-.’mat  lines  1  and  4  thru  12 
will  not  delay  or  stop  the  processing  of  a  CPITIC  message  being 
received  from  a  terminal. 

6,7  3,  Following  is  an  er  .inple  of  a  AMF  CRITIC  messages 
from  a  terminal  which  shall  be  lonverted  to  a  CRITIC  formatted 
message. 


at  u 


UNCLASSIFIED 


t: 


8.7  4 ,  r  orma  t  line  1 . 

07  4,  1  -  If  used  it  will  be  as  states  in  paragraph 

3  '.SC.  4  10. 

8|7  5.  FCRh’AT  LINE  2. 

8,7  5  1  ■'  OGQQ  -  This  is  a  required  field, 

indicating  that  this  is  sn  ATF  i-nessage.  The  absence  of  this  group 

(Jill  cause  the  I-S/A  AftPE  to  expect  a  fully  Pcrinatted  .Tiessage  If 

the  four  Q's  are  present,  the  I-S/A  AMPE  uill  search  for  the  next 
line  of  "U  CRITIC"  prior  to  rejecting  any  .nessage  The  stutter 
roup  not  be  transr. itted  electrically  nor  appear  on  the 

eedback  copy. 

8:7  a.  FORMAT  LINE  3 

8,7.6  1.  W  CRITIC  -  This  is  a  required  field  and  is 
the  precedence  of  the  inessage  and  indication  that  this  is  a 
CRITIC  message. 


8,7  7,  FORHAT  Lir..E 


8.7  7.  1.  CC  -  This  -ield  contains  a 


classification  coce  (TT.  SS.  C; 
present,  the  I-S/A  A!'’PE  'uill  n; 
of  tr  $  CRITIC  message. 

8,7  s.  line  4„ 

8,7  3.  1  -ul’  :z. 


a  1  n  s 

a 

Z'UJO 

character 

EE ) . 

If  this 

field  is  not 

or  d  e 

lay 

t  h  5 

processing 

Th  i  s 


an  op  1 1  ona  1 


It  13  the  Delivs''y  Distribution  Indicator  (DDI'  line, 
g  'J'  o  F-SRi'.AT  LI'E  5 


9  1  i.y  ClU'CI'C  .J.-i"!  23  ZNH  -  T,h  1  5  is 
'  present  it  .;ii;.  contain  the  prececence. 


: p  1 1 o na  1 
month. 


‘iT*; 


UrjCLASSIFIED 


8,7  .  10.  !■:  FK  GRIQINA'CR  and  TO  DIRNSA  -  These  are 

optional  fieldsi  indicating  the  originator  and  addressee  of  the 

message 

8.7  1  1.  FQRriAT  LINE  12. 

3^7  11  1.  CLASSIFICATION  -  This  is  an  optional 

field  ana  contains  the  classification.  codeixicrdCs)  and/or  special 
handling  instructions. 

8.7  12,  FORMAT  LINE  l2 

12,  1  QQQQ  -  The  stutter  group  signifies  the  end 

of  classifi’cation,  and  special  handling  structicns 

8<7i3,  format  line  12, 

8.7  13  1-  text  -  Lines  of  te.^t  should  not  e.xceed  69 

cha’'acte-'5  i-  eluding  spaces, 

8,7  14  FORMAT  LINS  16 

14  1  ENT -CF-, 'MESSAGE  -  A  recuired  field  At 

least  t'uo  (2)  line  feeds  a“d  4  N's  functions  must  be  received  bg 

I-c  A  AM=E.  If  not  recei'-ec,  the  1-5 'A  .AitRE  uiil  truncate  the 
CRI'i:  message 

8,8.0  2C-173  FORM  CPi'"  iC  E  INPUT 

^ ,  3  1  4  1  1  c  'u  1  n  .g  15  s  copy  of  c  ri  e  00  1  ~  3  Form  filled 

,:  u  t  -  0  -  a  0  -  I  ~  I C  message 


U.-JCLASSIFIED 


8.8  2.  The  following  special  instructions  will  apply 

when  filling  out  the  Joint  r.essage  Form  173  for  CRITIC  messages 

8,8  2.  1.  ‘The  CRITIC  precedence  presign  "WW"  will  be 
placed  in  the  ACTION  Addressee  precedence  block. 

8-82.2  The  word  "CRITIC"  will  be  placed  in  the 

"Or  1 g /Nes sag e  I  dent"  block 

8,8 . 2.  3,  '  CRITIC  ODI  "ZZZ"  will  be  used  in  the 

message  handling  instruction  block.  If  the  DDI  does  not  appear 

in  this  block/  the  1-3/A  At'iPE  will  build  the  proper  Format  Line 
4A.  but  will  not  reject  the  message. 

8.-8.  2.  4.  The  station  designator  of  the  station 

originating  the  CRITIC  .message  will  be  placed  in  the  “FM"  line. 

8.8  2.5.  The  "TO"  line  will  show  "DIRNSA"  as  the  only 

addressee. 

.  2  6.  Start  the  text  of  the  CRITIC  message 

with  security  classification  assigned  by  the  originator 
with  each  letter  sep.arated  by  a  space.  CODEWORD  (when 

assigned).  special  or  rc-stricti'.'e  handling  instructions- 
the  designator  ‘CRITIC".  CRITIC  number  and  throught  or 
idea  as  expressed  by  the  originator. 
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9 . 0  MAVY  ABBREVIATED  SI  VALIDATION  REQUIREMENTS. 


9.1  The  Navy  Abbreviated  SI  format  is  the  DSSCS  equivalent  of  Modified 

ACP  126  format.  It  is,  basically,  DOI-103  format  routed  to  an  LDMX  DSSCS 
NARC  derivative  "SMM"  and  is  used  only  as  a  vehicle  to  pass  the  appropriate 
information  from  a  DD173  Message  Form  from  a  remote  terminal  (RIXT)  to 
the  LDMX  for  formatting  and  routing  purposes. 
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(r  «i.  u:  a.  u 


unclassified 


character  'jill  require  the  1-5 /A  Af-’PE  co  process  the  iTiessage 
at  iriMEDIATE  precedence,  du*,  leave  t.he  characters  as  received 
-ollouing  the  precedence  is  a  space  -^unction  Following  the 
space,  are  the  Foucing  Indicators  (RI  s)  of  the  addressees  of  the 
i7.  essage.  All  RI's  nusc  start  with  the  letter  "Y",  or  the 
message  is  -ejected  D35CS  FI's  are  5l»  characters,  however, 
seven  letter  routing  indicators  are  authorized.  Nine 

routing  inoicators  are  autncr'iced  on  each  line  FI  s  can  not  pe 
split  across  a  line,  scch  as  toe  first  three  charac*:ers  on 

one  line,  the  end  of  line  -unctions  and  the  last  3  or  4 

characters  or.  the  nc-«t  line,  or  the  message  is  rejected  The 

mixing  o-  doth  P.'  and  ’  V  "  rcjting  indicator.^  in  tne  sane 

message  are  not  authorized,  or  the  message  i:-  rejected. 
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h  'DE'  Follc-'in.g  rfie  prosjgn,  is  a  space,  or 
IS  r  ^  e  c  t  e  d  After  the  space  :  ■  t  ‘ .  e  G  r  i  g  i  n  a  t  i  n  g 

V 1 1  ^  g  I  '  :  1  c  a  t  0  r  f  Di F I )  T  n ;  s  u  i i 1  s  j  w  a  ■  j  s  start  w ; t  h 

p-  the  message  i;  ■'s.'ctsd  F.olloijing  the  space 
after  t  r,  a  D  f  -  I .  it  t  a  '  ,o  t  c  h  o  t-  )  I  m  m  e  d  i  a  t  e  1  j  a  f  t  e  r  the 

‘atch  ra-i.  ■  r  o  space*  ii  1 1  e  four  :  :  g  ;  i  5t--'ior’  Ee-ial  Mump-jr 

'  2  5(N  T-^  .j  s  1  s  0  used  as  toe  an  j  ■:  f  message  .-a  1:  oat  ion 

.0  c  -  1  .r  f  0  r  r  a  t  lire  It  F  o  1  i  o  w  1  r  g  a  ?  ;.•  a  c  a  '^unction  a  -  t  e  r  tne 

r  1  re-C  •--- 1  1  e  TC”*.  The  ~G.-  nu  s  t  o  e  sil  numters.  If 
“von  O'- a  c  t  e  -  s  or  r  on  n  ^me-i..  characters  appear 


1  r  g  r  0 


.,C  I  -  1  u3  mp  e  c  a  1 
?  d  iP  e  s  s  a  g  e  l  5  e  e 


UNCLASSIFIED 


1  1.0  CD  FGRn  173 


1  This  form  has  been  designed  Por  use  with 
the  Optical  Character  Readers  <GCR)  ror  automatic 
processing  Scecific  instructions  on  preparation  o^  the  rorm 
are  considered  essential  in  the  interest  or  staridardiiation  and 
economy 


apply 

spaced 


I  1.2 

1  1  3 


Uhen  preparing  a 

All  lines  on  the 


DD  Form  173)  tne  P^i^owing  rules 

CD  Form  I'^O  will  be  double 


1 

20  d  0  u  b  1  e 
last  page 


1  4.  Each  page  or  the  message  shal 
spaced  lines  of  addressees  and/or 
which  may  have  less  then  20  lines 


have  no  mo'^e  then 
X  t,  except  for  the 


11.  5  Double  spacing  throughout  the  message  from  the 
horiiont-al  guidemar'xs  printed  at  the  left  and  right  ma'-gins  to 
the  end  of  the  text  area  is  mandatO“y/  except  info’'mation 
other  than  automatic  distribution  data  typed  in  the  D I  SIR  I  D'JT  I  ON 
b  1  0  c  . 

^  ^  6  F'or  OCR  preparat:on/  pen  and  ink  corrections/ 
initials/  annotations/  stamps  ana  other  markings  jili  not 
appear  on  the  message  form  Prom  t.se  security  classification  at 
the  to?  or  the  form  down  through  any  portion  oP  tpa  form 
reserved  for  m  e  s  s  a  c  e  addressees  =  m  d  ./  o  r  text 


'  •  '•“.•-'-  -.•  •W'-  .  %  \  .  .  •.  s  •*=  *.  •  »  •  ■ 


T-^n 


UrJCLASSIFIED 


tSi 


r-'. 


!.• 

>••• 

>.■ 

\ 

‘.• 
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1  1  .  7.  1,  PAGE  U'UriBER  -  A  two-c  harac  t  er  field.  Start 
at  the  left  .'nargin  and  the  number  muat  contain  two  digits. 

On  numbers  one  through  nine  the  leading  digit  will  be  zero. 

11.7  2  *rtESSAGE  PAGE  COUNT  -  A  two-character  field, 
~he  number  must  contain  two  digits  On  numbers  one  through  nine 
the  leading  digit  will  be  zero.  The  message  page  count  is 

mandatory  only  on  the  last  page  of  the  -message  However,  if  a 
pa-ge  count  is  used  on  all  pages  it  must  be  consistent 

117.3  CATE-Tir^E-GRCUP  ( DTG ) /RELEASER  TINE  -  A 

16  character  field  This  field  is  cotional  and  can  be 

left  blanlf  if  the  originator  desi'es  the  I-S/A  aNPE  to  assign  the 

DTG. 

1  1.7  4  PPECEDEtiCE  -  A  f  c  ur -c  h  ar  a  c  t  er  field.  The 

o-ecedence  assigned  to  action  and  information  addressees. 

Precedence  prosign  to  te  used  a-e'  UU)  for  CRITIC-  ZZ  for  FLASH- 
CC  for  Imimeaiate.  PP  -f^or  Priority.  and  RR  for  Routine. 
Unless  the  message  is  dual  precedence,  the  information  precedence 
blcck  will  be  left  blank 

1  l7,  5  CLASS  I F I  CAT  I CN:  A  four-character  field.  Enter 
the  proper  security  classification  designator  repeated  four 
tim.es.  e  -g  ,  UUUU  for  Un  c  1  a  s  s  i  f  i  e  d  .  EEEE  for  Encrypted  for 
transmission  Only  I'EFTC).  CCCC  for  Confidential.  SSSS  for 
Secret  and  TTTT  fo~  Top  Secret. 

1  1. t  6.  SPECAT  SPECIAL  HANDLING  DESIGNATCR-  A 
'our-c h arac ter  field.  This  block  will  not  be  used  on  DS3CS 
-m  e  5  s  3  ■:  2  s 


1  1  7  -  language  ,dt 

aracte-  -leld  f-'c*  .rail. 

‘  cell',  ere  d  to  tne  addressees 
'se-t  the  o-::?*'  LN" 


I -5-. A  AN=E  will  assign  the  proper  characters 


=■.1  L^^F  >  -  A  twQ- 

rlsn'-.  1-  she  message  is  to 
ng  -orm  -odh?*-  then  narrative, 
e  LNF  bis-:-  is  1  a  1 1  blank,  the 
fr.sm  the  internal 


n,  c  u  t  t  a  r  r,  1  n  a  1 


rr 


11  7  S  C-N-Z..- 

•:  ■  a  r  a  c  t  -e  r  f  :  e  1  j  a  :i  t  e  :  *  i  ;  ;  s  t  ^  ~ 

d  e  5  1  g  n  a  t :  t  o  i  i  n  1 1  -  ;  the  r  a  r  a  1  s  u  o  e  c  t 


1 1 C  )  -  .‘h  four 

a  TOur  —  craractor 
t  .‘1  e  T.  -e  s  s  a  g  e . 


'.■V  U'.m’ 


UNCLASSIFIED 


The  OCR  (ijill  read  the  characters  typed  in  the  content 
idicator  block  If  the  block  is  blank,  the  I-S/A  AMPE  will 

automatically  assign  the  approriate  CIC.  This  field  is 

optional. 

11  7  9  CRIGINATGR/MESSAGE  I  DEr4T  I F I C  AT  I DN :  -  A 

maximun  of  12  characters  field.  .A  unique  seq^uence  of  characters 
assigned  by  the  message  originator  for  positive 

or  1 g 1 na t or /mes 3 ag e  identification.  This  sequence  of  characters 
will  appear  on  each  page  of  the  message. 

1  1.7  10.  3CGK  -  A  th  r  ee-c  harac  ter  field.  For  bock 
messages  enter  "VE3".  for  ail  other  messages  leave  blank. 

11,7.11.  MESSAGE  HANDLING  I.NSTRUCTIONS  -  When 

required,  this  black  will  contain  Delivery  Distribution 
Indicators.  (DDI's)  and  ■''or  Cperating  Signals.  DDI's  and 

operating  signals  will  be  placed  in  the  message  handling  block 

at  the  top  of  the  DD  Form  173  in  the  following  order'  SOL/ZZS. 
DDI's  will  be  separated  from  the  operating  signals  by  a 

slant  (/)  sign,  Multiple  DD I  '  s /Gp er a t in g  signals  will  be  shown 
as  SGL  PNI  SCA/ZES  ZZS. 

I  1,7.  12.  FROM  -  (Leave  14  blank  spaces  from 

left  margin).  Identify  the  message  originator  using  the 
p-oper  plain  language  ad 'dress  (FLA)  provided  in  the 

curreit  DSSC.S  -a  dressing  publicaticns. 

II  ‘ 

■‘■■‘••7  13  TG  -  (Leave  14  blank  spaces  from  left 

margin).  List  action  addressee(3)  using  the  proper  PLA,  DAG> 
FDi  etc./  listed  in  the  app-opriate  docu.ments 

1  !.■'  1 •'1‘v-Z  -D  .'.--'E'zEEE '  i  -  (Les'-s  nine  blank  soaces 
-'-,cr,  left  .'■''a-'gin).  Z-  tr^  1  :  -  a  'jit.-,  the  first  infor.maticn 
addressee  t^pe  "Ir.iF3"  The  PL./-/  DAG,  PD,  et:  ,  for  information 
ad-dressee  s)  ‘wiil  oe  p,a-z?'d  directly  oeiC'jj  actioti  a*ddres5ee(5). 


UNCLASSIFIED 


1  1.7  15.  ZEN  -  Addressees  that  are  to  be  taken  care 
of  by  other  than  electrical  means  will  be  the 
responsibility  of  the  originator  and  will  have  ZEN  placed  in 
front  of  such  PLAs.  ZEN  will  be  placed  in  the  first  three 
positions  normally  containing  the  PLA  (IJ-  blank  spaces  from  the 
left  margin)  followed  by  a  space  and  the  appropriate  action 
or  information  PLA. 

ii.7.  16.  CLASSIFICATION  LINE  AND  CAVEAT(S)  -  Double 
linefeed  down  from  the  last  PLA  and  start  the  text  at 
the  left  margin.  Indentation  of  the  first  line  of  text  is  not 
permitted.  The  first  word  of  the  first  line  of  text  will 
contain  the  classification.  Other  information  may  be  contained 
in  the  classification  line,  in  accordance  with  paragraph  7. 7. 1.2. 

^^.7.16.1,  SPECIAL  ACTIVITY  OFFICER  ( SAQ )  -  All 
Special  Activity  Officer  (SAQ)  messages  addressed  to  U  S. 
Naval  commands  will  contain  the  additional  special  handling 
instructions,  "DO  NO  TRANSMIT  VIA  GPINTEL  BROADCAST", 
immediatley  following  the  classification  li^e.  and  prio~  to  the 
^our  Q '  5  Also  the  “Z''  signal  "ZYS"  will  be  placed  in  the 
message  handling  instruction  block.  If  this  phrase  is  in  Format 
Line  12-  then  the  operating  signal  ‘'ZYS”  must  either  appear 
in  the  message  handling  block  or  be  added  by  the  1-5/A  .ATFE. 


LTJCLASSIFIED 


1  2.  2. 

Following  example  is 

an  Af'F  messag 

optional  fields 

me  1  u  d  e  d . 

FORMAT  LINE  1 

ZC  ZCAEC  123-:  := 

FORMAT  LINE  2 

GGQO  1= 

FORMAT  LINE  3 

PTTMZ  >'Lu' 

FORMAT  LINE  A 

TT';-> 

FORMAT  LINE  AA 

Z^ZM  PP  A3C  GHA  EE  I 

"OR MAT  LINE  5 

P  R  022C'5ciZ  JAN  20  .  . 

FORMAT  LINE  6 

FM  OR  IGI.NATOP'i  1= 

FORMAT  LINE  “ 

TO  STATION  CNE  n:= 

FORMAT  LINE  8 

ir^FQ  station  TUO'lm 

FORMAT  LlfJE  12 

CLAS3IFICA 

T  I  a  N.;.;= 

FORMAT  Lir^E  12 

GCiGQ  ;  !  = 

FORMAT  LINE  12 

SUB  J  i  :> 

FORMAT  LINE  12 

TEXT 

-OR MAT  LINE  12 

-  - nnnn 

12  3 

The  abbreviated  mess 

age  format  w 

optional  fields 

and  es3e''tial  fields 

The  ETG  15  an 

ootional  field 

When  not  provided  on 

input  of  an 

T.  e  s  3  a  g  e  ,  the 

I-c/A  A-FE  will  as 

sign  the  DTG. 

f  e  e  d  t  a  c  V  c  c  p  4 

each  messace  entered. 

both  abbres'ia 

0  r  rna  1 1  ed  .  tiu 

St  be  auto n at  1  call g 

provided  to 

t  e  r  iT!  1  n  a  1 

1  2  A 

Following  is  b  r  e  a  '•  d  0  w  n 

of  each  forma 

e  with  all 


ill  contain 
a  :< a iT! p  i  e  of  an 
aoPreviatad 
An  electrical 
ted  and  fullu 
the  sending 

r  line  of  an 


,-^r^ir  I'n  ■?  3  B  £i  y  5  . 


:  c  r  *:  ij :  n 


?  5  -  a  3  a  p  . 


“CP •''AT  Lir-'£ 
t  -  iT.  5  3  a  e 


-  ZCZCADCIJIC  -  If  used,  it  will 
a “ c  u  e  n  c  e  .  channel  d  e  s i g  r  a  t  o  r . 

lens  i>ill  De  handle  as  stated 


up 


■:  a  o  =  e  the 


A.  ':F 


t 


a 


0  3  “5  n  C  5 


e  <  D  ec  r 


^  2  4.  3.  FORMAT  LINE  2  -  PTTMZYUW  -  The  precedence 
indicated  by  the  "P"  is  a  required  field  The  LMF  ( TT ) ,  DSSCS 
security  sentinel  (M)  and  CIC  are  optional  and  will  be  inserted 
by  the  1-5/  AMPE  if  omitted 

^  2_  4  4  FORMAT  LIiNE  4  -  TT  -  A  two-character 
classification  code  (TT<  SS.  CC,  UU<  EE<  and  RR  )  This  is  an 
optional  field, 

12.45  FORMAT  LINE  4A  -  2KZ'4  PP  ABC  GHA  DE  -  An 
optional  field.  Delivery  Distribution  Indicator  (DDI)  line- 
if  used/  this  field  must  be  complete.  The  number  of  DDIs  may  vary 
with  each  message  up  to  a  maximum  of  14.  If  a  DDI  is  not 

assigned  to  the  message/  the  I-S/A  AMPE  will  build  the  format 

line  using  ''ZKZ/,  PP  SO  A  DE"/  in  accordance  with  DO  I -103. 

1  2  4.  6.  FORMAT  LINE  5  -  P  R  022056Z  JAN  83 
Optional  field.  Contains  the  precedence  prosignis)/  DTG  and 
any  OPSIGS  which  are  required  ^or  denoting  special  handling  or 
other  communications  functions.  Both  single  and  dual  precedence 

may  be  indicated.  If  the  message  is  dual  precedence/  then 

the  precedences  are  required/  and  the  D^G  is  optional. 

12  4.7.  FORMAT  LINE  6  -  FM  ORIGINATOR  -  Required 

field/  The  PRCSIGN  "FM"  and  PLA  denoting  the  originator  of  the 
message. 

1  2  4  8.  FORM.AT  LINE  7  -  TO  STATIOTJ  ONE  —  Required 

field  The  PROSION  "TO"  followed  by  the  PLA<s>/  DAGs/ 
AIG/  etc.  ‘"as  appropriate)  which  denote  the  action  addresseeCs) 
O'  the  message/  in  accordance  with  appropriate  DSSCS  addressing 
d  0  c  u  m  e  — 1 1  3 

1  2  4  9  FORMAT  LIL'E  B  -  INFO  ST-'ICN  TLC  -  A 

r  a  q  u  1 '  e  0  field  if  a  o  *  1  i  c  a  o  1  e  for  t  r  e  o  a  r  1 1  c  u  1  a  r  .message: 

tr.e  FRCSIGN  'IrtFO"  *;ll;w?j  by  applicsDle  addressee  in-oicato^s 
'same  as  as  oaragraph  12. a  .3.  above) 

^  2  a  v;  FORMAT  LIr‘E  II 


',1.  *.'•  '■".  ^"■.'  ^'V  '•* J  ‘ '  ^“jv '  y  ".■  v  -j* 

UNCLASSIFIED 


1  2 

A.  10.  1  Un c 1  as s 1 f i 0 d  is  abbreviated  as 
without  spacing  between  the  letters. 


'UNCLAS" 


124  10.2.  Unclassified  Encrypted  For 

Transmission  Cn i u  is  abbreviated  as  "UNCLAS  EFT  0".  UNCLAS 
without  spacing,  -followed  Dy  a  space  and  E  F  T  0  with  each  letter 
sepa"'ated  by  a  space 

12,4  10  3.  Gther  classifications,  each  letter 

of  the  classification  must  be  separated  by  a  space,  e.  g.,  C  0 

N  F  I  D  E  N  T  I  A  L  , 

l2  ‘*.10.4.  Any  special  handling  instructions, 
codewords,  or  caveats  that  follow  the  classification  shall  be 

separated  from  it  by  two  spaces  and  also  separated  from  each 
other  by  two  spaces.  In  the  classification  line,  wo^ds 
shall  not  be  hyphenated  and  continued  into  the  next  line 
Each  line  shall  end  with  a  completed  word.  Caverts  will 

be  D^chen  at  a  soace  but  net  hyphenated  at  the  end  of  the 
lire  or  with  a  slant 

124  11.  FCRNAT  LIME  12  -  QQQO  -  Required  field, 
Stott?-  group  which  signifies  the  end  of  the  classification 
line  Tn  13  stutter  group  will  not  be  transmitted  electrically 
or  aopear  on  tne  feedbac-.  copies 


12  ill 
line  12,  i; 
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1.  ether  information  may  be  contained  in 
a  c  c  0  T' d  a  n  c  e  o)  1 1  h  p  a  r  a  g  r  a  p  h  7 .  7 . 1 2 . 


iO" 


FCRfdAT  LINE  II 


tart 


w  1 1  n 


SUS  J  -  Subject  Line 
the  letters  "SUSJ". 


celled  by  the  originator,  t'e 
.■ni  --  uill  contain  to.?  lettei' 


'  — C  ' 


b/  /-> 


SU5  J  " 


1  2  ~  ’-'2  FCr'’'A''  line  12  -  TE'T  -  Reguired  fie 

test  srcull  -ot  esos^.j  characters,  including 


Th  i  s 
If  a 
will 


1  n  £?  s 


w  4j  L 


~  Id.  FC-MAT  LIh.E  16  -  (EEM)  -  Required  ^leid 


EEiM  se'tuenc 


Th  e 

CF  2  Carriage  .detu-ns,  3  Line  reeds  and  4 
t  as  a  m  1  1  r  u  m  2  line  f  e  1  s  ana  4 


m  0^  im  M  M 


fL  o:  iL 


UNCLASSIFIED 


13.3,  1  Positions  30  thru  33  is  the  card  count.  The 
card  count  is  the  total  number  of  80-character  records  in  the 
card  message.  including  header  and  EOT  card.  Left  most 

positions  are  filled  with  zeros  when  they  contain  no  other 
numerics  "MTMS"  mag  be  used  in  this  field  to  facilitate  the 
processing  of  messages  in  batches  However,  the  actual 

record  count  must  be  placed  in  the  record  count  field  of  the  EOT 
(last)  card.  The  TI  lire  is  NOT  included  in  the  card 
count  I-  thij  field  is  less  than  four  characters,  the  numbers 
do  not  match  che  card  count  field  in  the  EOT  card,  or  any 
characters  other  then  “•ITh'^  appears  in  this  i  e  1  d ,  the  .message 
will  oe  rejected 

13.A  Cards  1  through  text  cards  are  the  same  as 

paragraphs  7.7.3  thru  7.7.'’, 4. 

•i  3  5.  LAST  CARD  -  EOT  CARD.  The  final  record  of  a  card 
message  is  used  to  identify  the  originating  station,  SSN, 
TOF,  Card  count,  TCC,  associated  tranmission  information  to  the 
addressee  after  the  header  (Format  Line  2),  is  strapped  from  the 
message  by  the  receiving  1-5/A  AN'^E  The  EOT  is  an  SO-position 
~ecord  for  card  and  magnetic  tape.  The  EOT  consist  of  a 
repeat  of  header  (format  line  2)  information  starting  with 

the  precedence,  includin.g  .all  intervening  elements,  and  ending 
with  the  character  before  the  s  tar  t-o  f-r  o  u  1 1  ng  signal  When  MTriS 
15  used  in  the  -ecord  count  field  of  form.at  line  2,  the  actual 
"ecord  count  must  be  placed  in  the  EOT  card  The  remaining 

positions  are  filled  with  separators  (spaces)  up  to  the 
position  required  for  tne  en q -o f - tr anm i s s i on  sigrals  (ECTS).  Any 
errors  in  positions  i  thru  position  30  is  handled  the  same  as 
paragraphs  7.7.-.1  through  7.7.2.10.  Errors  i--  the  ca-d  count  field 

shall  be  handled  the  seme  as  parag-aph  \Z  2  1  above, 

1  4  lO >^2rUE.T  i  C  T..'-m,;r  -  ,nfr''’AT 

I  4,  1  D5SC5  o-.at;o-5  havmg  .magnetic  tape  capability, 
the  -ovmat  is  ‘‘toe  same  as  that  of  a  CARD  message  (oaragraph 


14  -2.  The  text  reiterial  on  c-na'^netic  tape  i-nay  consist  o 

a  uiie  variety  C'  information  reccroeo  in  either  structure 
or  non-  strut  turet  forirats  je  pending  upon  the  tupe  or  associated 
computer  system.  Computer  magnetic  tapes  may  contain  streams 
of  binary  signals  in  no  commor  codes  or-  larguate.  Regardless  of 
the  type  of  irforration  used  in  the  tsjt  'cooed  or  bina-y 
stream*/  the  format  (structured  or  non -structured),  and  the 
arrangement  o-^  bits  as  ■•ecorseo  or  th?  source  tape  is 

preserved  ac  curstely  Bits  -ay  e  aooac  to  t  ^  c-  oinarj  ;  cream 
to  create  ASCII  cnaract  ‘r  s  for  t  r  3  nm  i  s  s  i  on ;  hoii'ever,  tnis 
must  be  a  :  c  0  n  0  1  !  s  h  s-  0  in  a  s  t  .s  a  r  d  m  a  n  n  a  t-  to  a  1  .  0  u  the  -  e  c  e  1  v  i  n  g 
station  to  strip  t,-ese  adceo  bits  ano  Te'to''d  on  the  receive 
magnetic  tape  a  mirror  image  of  the  bit;  as  recorded  on  the 
source  tape 


CL  -1, 


15,0 


1  5* I  The  Air  Force  performs  unique  Data  Pattern  message  processing  at  the  Lowry 
TCC  known  as  "CIC  Shredout" .  Shredout  differs  from  normal  Data  Pattern 
Processing  in  that  received  messages  go  straight  to  an  Intermediate  Access 
Storage  (IAS) .  The  messages  are  placed  on  IAS  until  a  "pull"  is  requested 
by  the  customer.  Messages  are  checked  for  specific  RI ,  CIC,  LMF  and  SEC 
combinations,  and  are  placed  in  separate  file  groups  on  disc  based  on  those 
combinations . 


The  current  names  of  these  file  groups,  along  with  their  block  size  on  out¬ 
put,  security,  LMF,  CIC  and  Routing  Indicators  are  listed  in  the  table  below. 


FILE 

BLK  S2E 

SEC 

LMF 

CIC(s) 

RI 

27110150 

800 

U,E 

C 

FFJJ 

RUVEGAA 

27110151 

2200 

U,E 

C 

FFEH 

DFEH  IFEH 

FME2 

FMF2 

RUVEGAA 

27110152 

1500 

U,E 

D 

FDD3 

RUVEGAA 

LOVJRYACD 

80 

U,E 

C 

FDDB 

FDD2 

RUVEGAC 

27110154 

1500 

U,E 

D 

FFEA 

RUVEGAA 

FIT2UNCL 

80 

U,E 

C 

ADJA 

ADJC  ADJT 

AMBL 

AHDT 

RUVEGAD 

ANBC 

AD 

27110156 

1500 

U,E 

D 

FFEB 

RUVEGAA 

27110157 

800 

U,E 

C 

FFCI 

RUVEGAA 

27110158 

800 

U,E 

C 

AFAG 

DFAG  FFAG 

NFAG 

IFBB 

RUVEGAA 

FITZBIUE 

1500 

U,E 

B 

ANCE 

RUVEGAD 

Messages 

arriving  at 

the  TCC  having  the 

above 

combinations  of 

RI, 

CIC,  LMF  and 

Security  Classification  must  be  stored  in  such  a  manner  that  all  messages 
associated  with  a  given  file  group  may  be  pulled  from  IAS  upon  request  and 
written  to  a  specified  magnetic  tape  in  the  appropriate  format. 

1  5,2.  ^  pull  of  a  specified  shredout  file  group  will  be  activated  by  operator  request 
from  the  system  operator's  console.  Each  shredout  file  group  has  predetermined 
output  format  requirements  for  writing  to  magnetic  tape.  These  requirements 
and  the  files  to  which  they  are  applicable  are  listed  below: 

1  5,-^1.  Tape  labels.  The  following  files  will  be  written  to  tape  preceded  by  an 

IBM  standard  label;  Z7110150,  27110151,  27110154,  27110156,  27110157  and 
27110158.  The  modules  responsible  for  output  to  tape  must  insure  that 
the  tape  being  written  to  has  a  label  on  it.  The  label  must  be  read,  vali¬ 
dated,  updated  appropriately  and  rewritten  to  the  tape  prior  to  delivery 

of  any  message  data. 

1  5j2.  Sequence  nu,mber.  File  27110151  has  a  requirement  for  the  application  of 
a  sequence  number  to  each  record  written  to  tape.  The  starting  sequence 
number  for  the  file  will  be  supplied  by  the  operator.  Each  message  delivered 
to  that  tape  will  have  a  sequence  n'umber  updated  by  one  from  the  previous 
message. 

1  Block  size.  Message  records  written  to  tape  must  be  buffered  by  the  block 

size  indicated  in  the  table  listed  above  in  I. A.  The  maximum  block  size 
is  2200  characters  for  file  27110151. 


,4.  !?*cord  size.  The  files  which  contain  messages  of  BB  or  DD  LMF  will  have 
variable  length  records.  Those  records,  however,  should  have  a  maximum 
size  of  1200  characters.  Provision  is  .made  for  messages  which  have  greater 
than  1200  character  records.  .Ml  "C"  L.'^iF  files  will  have  fixed  length, 

80  character  records. 

5.  Tape  Density.  All  files  except  for  LOW.RYACD  will  bo  written  to  magnetic 
tape  at  1600  Bits  Per  Inch  (BPI) .  The  LOWRYACD  file  will  be  written  to 
tape  at  800  BPI. 

,6.  Output  Character  Set.  All  files  e.xcept  FITZBINE  will  be  writte.n  to  tape 
in  the  EBCDIC  character  set.  The  FITZ3IEE  file  will  have  header  and 
trailer  written  in  EBCDIC  and  all  data  between  will  be  written  in  Binary. 

Additional  requirements.  The  modules  responsible  for  outputting  shredout 
files  sljall  accumulate  for  output  to  the  printer,  a  list  of  the  Autodin 
header,  the  te.xt  header,  the  te.xt  trailer  and  the  Autodin  trailer  of  each 
message  delivered  to  magnetic  tape.  Only  the  Autodin  header  and  trailer 
will  be  accumulated  for  the  FITZBINE  file. 

Statistics  must  be  maintained  on  the  total  number  of  IAS  slots  in  use, 
both  in  term.s  of  total  numbers  and  percentage  of  IAS  slots  available. 

Statistics  must  be  maintained  as  to  the  num.ber  of  messages  in  each  file 
group  and  these  statistics  should  be  output  each  time  a  shredout  file 
pull  is  completed.  These  statistics  should  also  be  available  by  operator 
request  at  any  time. 

The  I-S/A  AMPE  operator  must  receive  a  notification  and  be  alerted  by  an 
audible  alarm  v/henever  the  number  of  IAS  slots  in  use  for  any  file  group 
reaches  851;.  Once  this  condition  exists,  the  operator  is  to  be  notified 
every  five  minutes  until  the  condition  subsides.  If  the  number  of  slots 
in  use  reaches  95%  the  operator  is  to  be  notified  every  minute  until  the 
condition  s'ubsides. 

The  o.nerators  will  have  the  capability  of  rebuilding  a  specified  shredout 
file  from  history.  Parameters  for  this  procedure  should  include  file  name, 
file  time  and  'JMI  param.eters.  This  capability  m.ust  include  recovery  of  ail 
messages  in  each  curre.nt  file  in  the  event  of  a  catastrophic  loss  of  the 
shredout  disc. 

Software  •..•ill  have  the  capability  of  purging  messages  associated  with  the 
largest  previous  file  group  when  I.AS  resources  reach  certain  critical  usage 
thresholds . 

Th.e  integrity  of  the  Shredout  File  should  be  maintained  through  system  reload, 
restart,  degradation  or  in  the  event  of  a  s^/stem  operating  system  crash. 

In  order  to  reduce  rr-:uirem,cnt3  for  histor-y  recovery  of  previous  shred  files 
(i.e.,  those  'which  ha'/e  already  been  delivered),  messages  associated  -with  a 
pull  •./ill  be  maintained  on  IAS  until  a  subsequent  pull  on  that  file  is  accom¬ 
plished.  Thus,  once  a  file  ha.s  been  pulled,  those  messages  become  a  part  of 
the  previous  pull  for  that  file  name. 


SERVICE  MESSAGES 


A.  Description  and  Use. 

1.  Forirat  and  Classification.  Standard  system  generated 
service  messages  are  generated  in  JANA?  format  for  the 
R-Community  (AT  I>MF)  .  Service  messages  for  the  Y-Community  are 
generated  in  DOl-103  Special  (ACP)  format  (AT  LMF) .  Format 
and/or  media  exchanges  are  performed,  as  necessary,  on  output. 
All  system  generated  service  messages  include  FL4  and  are 
considered  either  Unclassified  (R-Commun ity )  or  requiring  "No 
Special  Handling"  ( Y-Commun i ty) .  A  proper  TRC  is  inserted  when 
the  routing  indicator  requires  it.  The  word  "UNCLAS"  appears 
in  the  text  of  R-Community  service  messages,  but  not  in  the 
text  of  Y-Community  service  messages. 

2.  Service  Message  Header.  The  OSRI,  OSSN  and  TOF  of  the 
service  message  itself  indicate  the  transmitting  AMPE,  the 
sequence  number  of  the  service  message,  and  the  time  the 
service  was  generated.  in  those  conditions  in  which  the 
validity  of  the  information  is  ephemeral  (e.g.,  a  "ZID" 
message) ,  the  tOF  should  be  noted  if  there  is  doubt  that  the 
information  is  current. 

3.  Precedence .  Precedence  of  the  service  message  is  equal 
to  the  precedence  of  the  message  being  serviced  except  as  noted 
in  the  remarks  on  a  specific  message  type.  In  cases  where  a 
se+vice  is  sent  in  reference  to  a  recognized  Critic,  the 
service  will  be  Flash  or  Immediate.  No  service  message  is  ever 
sent  at  W  precedence. 

4.  Disposition  of  Rejected  Messages.  A  message  which  is 
unacceptable  due  to  an  error  is  rejected  on  Modes  I  and  V  and 
an  RM  (Mode  I)  Or  RT  (Mode  V)  sequence  is  transmitted  by  the 
AMPE  to  the  connected  station.  An  unacceptable  message  from  a 
Mode  II  cannot  or  will  not  be  subject  to  electrical  (RM/RT) 
rejection  and  is  removed  from  the  system  on  generation  of  the 
service  message. 

5.  cited  Header  Information.  The  OSRI,  OSSN  and  TOF  cited 
in  the  service  message  text  are  derived  from  the  JANAP  header. 
In  those  cases  in  which  the  data  received  from  the  terminal  in 
the  header  position  is  garbled  or  is  not  a  header,  this  garbled 
data  will  appear  in  the  service  message  text  in  lieu  of  the 
header.  Where  the  service  message  text  cites  an  ACP  message, 
the  OSRI  and  OSSN  are  constructed  from  the  CID  and  CSN.  The 
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TCF  is  tht^  SOH-IN  tine  of  the  message.  If  the  serevice  message 
sites  an  R-Corrmunity  high-praceienca  message  accepted  with 
errors  in  the  OSSN'  and 'or  TOF  fields(s),  the  errored  fieldts) 
will  be  male  all  -I's  (i.'^.,  19^?  an.i/or  9999999). 

6.  l>tiission  of  CD/CSN.  JiThere  the  service  message  pertains 
to  a  JANA?  format  user  employing  'TI  lines  and  does  not  concern 
*:he  Tl  line  itself,  the  CD  and  CSN  will  be  cited  as  received. 
Ibis  is  not  done  for  sar'/ices  pertaining  to  AC?  format 
messages,  since  the  OSRI  and  OSSN  ara  derived  from  the  CID-CSN 
and  repetition  of  the  CID-CSN  is  not  necessary. 

7.  Terminal  Action.  It  should  be  noted  that  message 
garbling  and  resultant  rejection  c'n  be  the  result  of 
malfunction  in  terminal  equipment,  signal  path  (especially  Mode 
II  and  Mode  V),  or  AMPE  equipment.  If,  in  any  case  in  which  a 
message  is  rejected,  a  careful  check  of  the  message  itself 
shows  no  error,  and  re-entry  is  successful,  equipment  or  path 
malfunction  should  be  considered  as  a  cause  and  appropriate 
action  taken.  Even  if  the  message  is  accepted  by  the  AMPE  with 
no  errors  in  those  message  portions  which  it  validates,  garbled 
message  text  will  result  in  delay  in  delivery  and  probable 
ser^/ice  action. 

The  reader  is  also  referred  to  the  current  editions  of 
JANAP128,  DOI103,  ACPI  27  and  NTP4  for  additional  information. 

8.  Routing  of  Segt/ice  .Messages .  Service  Messages  are 
noted  in  the  examples  as  being  routed  to  "OSRI”  or  "SMRI". 

Only  JANAP  format  Invalid  Routing  Indicator  service  messages 
are  routed  to  the  OSRI  of  the  message-  All  other  services  are 
routed  to  the  stored  Service  Message  Routing  Indicator  which 
the  terminal  has  designated  for  sem/ice  action.  In  the  case  of 
a  R/Y  channel,  the  SMRI  is  that  of  the  Y  component  for  all 
except  invalid  RI  services,  so  that  all  service  messages  on 
those  channels  except  those  citing  invalid  routings  on  JANAP 
format  messages  will  be  routed  to  the  Y-community  RI.  If  the  R 
component  of  a  combined  R/Y  channel  uses  ACP  format,  invalid  RI 
sem/ices  for  R-Community  messages  are  sent  to  the  SMRI  of  the  R 
component . 

9.  Terminal  Action-  The  "Action  Required”  section 
indicates  the  action  which  must  be  taken  by  the  terminal  on 
receipt  of  the  ser’/ice  message.  This  is  advisory  only  and  is 
intended  to  expand  on,  not  supersede,  terminal  station 
operating  instructions,  JANAP128,  DOI103,  ACP127  or  NTP4. 


i . 


21 


2 


10.  Special  Service  Message  Prece  iance  _Char.ge  Cor.'iition. 
'.v'r'.en  the  R-lov.ponent  cf  an  R/Y  channel  is  ajt;'.oricei  to  entar 
HC?  messages,  any  Y-Ccnrr.unir.y  service  perPinent.  cc  an 
R-Cocua'anity  ECP  message  which  normally  would  be  ECP  precedence, 
is  made  Flash  instead,  since  ECP  is  not  valid  for  the 
Y-Comjtun  ity . 

3.  Service  Massage  Exam.ples_. 

The  following  sef/ice  massage  samples  cite  only  the  actual 
text.  The  header  format  is  shown  in  the  first  example  as 
generated,  but  the  header  as  well  as  the  TSSN  and  EOMS  or 
Trailer  Card  are  modified  on  transmission  as  appropriate  to  the 
receiving  terminal.  The  generating  AMPE's  Service  Operator 
Position ( SOP )  is  an  addressee  of  the  service  message  except  as 
noted  in  the  examples.  Examples  show  texts  of  both 
communities,  with  and  without  the  cited  CID-CSN. 

The  headers  of  ser'/ice  messages  generally  conform  to  the 
examples  below,  one  for  each  community.  These  are  the  headers 
as  generated , -as  noted  above,  format  and  medium  exchange  will  be 
performed  as  necessary. 

R-Community  Service  Message  Example.  (Invalid  Header  text 
is  used  for  illustration  only). 

RTTUZYV".-?  RUXXCSD4213  1231506-UUUU— RUXXABA  RUXXCUA. 

ZNR  UUUUU 

(TEXT)  UNCLAS  SVC  ABA127  RUXXABA1296  1231504 
(TEXT)  INVALID  HEADER  REJ 

44213 

(2  CR,  8  LF) 

NNNN 

REMARKS:  ZTVW  -  CIC  indicating  a  service  message 

RUXXCSD  -  CSD  indicates  a  system  generated 

service  message;  for  an  AMS  service 
message  this  is  CSR. 

RUXXCUA  -  SOP  RI  reserved  for  system  genera¬ 
ted  messages. 

-  TI  line  of  cited  message.  Not 
present  if  terminal  does  not  use 
TI  lines  or  if  message  refers 
to  CD  or  CSN. 


ABA  127 


y-COi~T,jr!  ity  Service  Message  Example  (Invalid  Header  text  is 
csed  for  illustration  only). 

O'TTMZYV.v  YEXXSVD4214  1231507-MNSH — YEXXBA  YE.XXSZ 

ZNY  MMN’SH 

7  •/  u 

2  EM 

(TEXT)  Sv-C  AYA143  YEXXAYA1402  1231503 

(TEXT)  INVALID  HEADER  REJ 

44214 

(2  CR,  8  LF) 

NNNN 

RE.MARKS:  YEXXSVD  -  SVC  indicates  a  system  generated 

service  message;  for  the  A.MS 
service  message,  this  is  SvR. 

YEXXSZ  -  SOP  Rl  reserved  for  system 
generated  service  messages. 

ZYH  -  This  operating  signal  appears  onl 
in  service  messages  of  Flash  and 
Immediate  precedence. 

ZEM  -  This  operating  signal  indicates 
that  start  of  text  follows. 

AYA123  -  TI  line  of  cited  message.  Not 

present  if  terminal  does  not  use 
TI  lines  or  if  message  refers  to 
CD  or  CSN.  A  4-digit  CSN  is  used 
on  ETR  channels. 


Note  that  the  word  "UNCLAS”  does  not  appear  in 
Y-Community  service  messages. 

1.  REPROTECTION  REQUIREMENT,  GENERAL. 


TEXT 

UNCLAS  SVC  ABA123  RUXXABA1234  1231225 
REPROTECT  TO  ALL  ADDRESSEES 


PRECEDENCE:  Message 

COMMUNITY:  Both 


ADDRESSEES: 


SMRI,  SOP 


CIM  CATEGORY: 
CO>a:iTlONS: 


None 

Framing  character  error;  internal  AMFE 
error;  invalid  character  on  ASCII  TTY 
channel;  cancel  received  in  mid-message 
from  Mode  I  Tl-using  terminal. 

AMPE  ACTION;  Message  rejected. 

ACTION  REQUIRED:  Reprotect  message;  Mode  I  terminal 

monitor  for  equipment  trouble  if  service 
'.yds  not  result  of  operator  action;  ASCII 
TTY  terminal  check  tape  or  equipment. 

2.  INVALID  MESSAGE  HEADER. 


TEXT: 

SVC  ACA124  YEXXACA1235  1231226 
INVALID  HEADER  RSJ  {or  ACC) 


PRECEDENCE: 
com  UNITY: 
ADDRESSEES: 
CIM  CATEGORY: 
CONDITIONS: 


AMPE  ACTION: 


Message 

Both 

SMRI ,  sop 

IHR  (no  CIM  for  an  ”ACC"  condition) 
invalid  header  through  star t-of-rou ting 
except  JANAP  FL2  security  fields;  no 
straggler  sentinel  in  Y-Comm  FL3;  no  SOR 
(space)  in  ACP  format  message.  Data 
found  in  a  card/block  following 
the  EOR  in  a  multi-card  card/ 
magnetic  tape  message.  No  second  EOR 
found  following  a  PLTS  header  in  a  card 
or  magnetic  tape  message. 

Message  rejected,  except  for  high- 
precedence  accept  condition.  An 
R-Community  high-precedence  jANAP 
message  may  be  accepted  with  some 
errors;  in  this  case  the  service  text 
reads  "ACC"  in  lieu  of  "REJ." 
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ACTION  REQUIRED: 

if  message  was  rejected,  correct  as 
necessary  and  reprotect.  If  accepted. 

message  may  be  received  by  addressee  (s) 

with  erroneous  fields  (9's);  correct  and 

reprotect  as  suspected  duplicate  at 

discretion. 

3  . 

INVALID  ROUTING 

FIELD. 

V*  .  >•” 

TE  XT  r 

%• 

UNCLAS  SVC  ABA125  RUQQABA1237  1231232 

INVALID  ROUTING 

FIELD  REJ 

PRECEDENCE: 

Message 

COMMUNITY: 

Both 

1..  *  .  • 

ADDRESSEES: 

SMRI,  SOP 

CIM  CATEGORY: 

RFR 

•** 

CONDITIONS: 

Errors  in  routing  indicator  field. 

AMPE  ACTION: 
ACTION  REQUIRED: 


including  any  character  that  is  not 
Lower  case  five-level  teletypewriter, 
ASCII  upper  case  alphabetic  (capital 
letters)  or  a  valid  separator  (space) • 
error  in  end-of-line  sequence; 
erroneous  or  missing  end-of-routing 
symbol  or  sequence:  RI  of  over  7 
characters;  a  y-Community  message  has 
an  Rl  not  beginning  with  Y;  mixed  R  and 
y  RI's  in  any  message  from  an  R/Y 
channel . 

Message  rejected. 

Correct  RI  field  as  required  and 
re  protect  to  all  addressees.  No 
delivery  is  made  to  any  Rl. 


4.  INVALID  security  FIELD  Or  INPUT  SECURITY  MISMATCH. 
TEXT: 

UNCLAS  SVC  RUXXBCA1238  1231234 
INVALID  SECURITY  FIELD  -  REJ 

-  SEC 

-  SRC  (R-Comm  Only) 

-  TRC  (R-Comm  Only) 

-  TCC  (Y-Comm  Only) 

PRECEDENCE:  Message 

COMMUNITY:  Both  (note  that  not  all  codes  are 

applicable  to  both  communities) 


ft-  lii^'liw  ifai  lAiVW 
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AM?E  ACTION:  Message  Rejected. 

ACTION  .REQUIRED:  Correct  security  field  error  and 

reprotect  message  to  all  addressees. 
If  rejection  is  due  to  input  security 
mismatch  a.nd  the  message  security  or 
.ALPS  usage  should  he  authorised,  con¬ 
tact  the  AMPE  fcr  assistance.  If 
rejection  is  result  of  attempt  to 
transmit  an  unauthorized  message 
security,  consult  terminal  operating 
procedures  or  reprotect  message  by 
other  means  if  possible. 

UNAUTHORIZED  USE  OF  EMERGENCY  COMMAND  PRECEDEi:CE  (Y)  . 


TEXT: 


UNCLAS  SVC  ABA127  RUXXABA1239  1231341 
UNAUTHORIZED  USE  OF  ECP  REJ 


PRECEDENCE: 
COMMUNITY: 
ADDRESSEES: 
CIM  CATEGORY: 
CONDITIONS: 


AMPE  ACTION: 
ACTION  REQUIRED: 


Immedia  te 
R-Only 
SMRI,  SOP 
I  HR 

Terminal  not  authorized  use  of  ECP 
has  attempted  to  enter  message  of  that 
precedence;  a  garbled  entry  contained 
the  letter  "Y"  in  the  precedence 
f ield . 

Message  Rejected 

If  reject  was  caused  by  an  error, 
correct  message  header  and  reprotect; 
if  message  is  ECP  and  terminal  should 
be  authorized  its  use,  contact  the  AMPE 
for  assistance.  Re-entry  of  an  ECP 
message  as  a  result  of  a  later 
discontinued  alternate  route  condition 
must  be  in  accord  with  procedures  out¬ 
lined  in  JANAP128/ACP127 . 


unauthorized  use  of  a  collective  ROUTING  INDICATOR  (CRI) . 


TEXT: 

UNCLAS  SVC  RUXXBCA1242  1231343 
UNAUTHORIZED  USE  OF  CRI  REJ 


rj!'  Allien  Ciic  c.'iaHiic.  is  net  cicdfco 

^.xEu);  terming !  nci  aL.':.^or  izeJ  mLPS 
use  atteii^ptec  lo  enter  ALPS  message 
(TRC/TCC).  Errors  in  otner  security 
fielas  resi.lt  in  reject  cedes  as 
incicatec  by  tne  jiagra.r,  eele.r. 

r. ~ eOr.rr. ,  Fi,2 

RATCZYUW  RUXXCSAOOOl  123234 1-CCBB—RUXXCSA. 

SEC  SEC  TRC 

'^-Comrn,  FL2 

RATMZYU'.v  YEXXSVAOOCl  1a32341-:wSH--Y£XXSV. 

SEC  SEC  TCC 

R-Coitm,  FlA 

-Z:jR(sp;  -ZN'R(sp)  Zi.R  UUU8B/AAAAA/BBBB/CCCC/DLDD 

REJ(uARAP123)  REu(AC?127)  SEC  TRC  SRC  (up  to  4  SHD's) 

Y-Comm,  FL4 

-Z,\Y(  spj  -Zi\’Y(Sp)  Zi\Y 

R£J(D0I-103)  REJ(D0I-103  Special)  SEC  TCC 

Note  that  an  error  in  R-Community  TRC  field  is  coded  as  -TRC  whether  or 
not  a  true  TRC  may  have  been  intended.  The  same  is  true  of  an  erroneous  FL4 
termination  which  appears  as  an  SHD(SRC)  error  even  though  no  SHD  may  actually 
be  intended,  as,  for  example,  the  presence  of  reaundant  characters  which  the 
program  may  interpret  as  an  invalid  Special  Handling  code. 


••1^3  sage 
3ot:h 

S-IRI,  SOP 
RFR 

A  Collective  Rl  beginniag  with  RCHR 
(R-Conununity)  or  YCKR  , Y-Commun i ty )  has 
been  selected  in  a  tiessage  from  a  ter¬ 
minal  not  authorised  its  use.  Also 
generated  when  a  Collective  RI  beginning 
with  RUCH  (R-Communi ty)  or  YECR 
(Y- Community)  has  been  detected  in  a 
message  from  any  terminal. 

.Message  Rejected.  Other,  non- collective 
RI 's  are  not  protected. 

If  reject  caused  by  error,  correct 
error  and  reprotect  message  to  all 
addressees.  If  an  attempt  was  being 
made  to  re-enter  a  collectively  routed 
message  received  from  the  A.MPE,  consult 
local  station  procedures  for  correct 
message  handling,  if  the  use  of  a  CRI 
is  legitimate  and  should  be  authorized, 
contact  the  AMPE  for  assistance.  If  the 
use  of  a  CRI  is  not  authorized,  reprotect 
message  using  the  correct  single  RI  for 
each  of  the  collective  addressees. 

INVALID  RECORD  COUNT  FIELD . 

TEXT: 

UNCLAS  SVC  RUXXBCA1244  1231145 
INVALID  RECORD  COUNT  REJ 

PRECEDENCE:  Message 

COMMUNITY:  a^th 

ADDRESSEES:  SMRI,  SOP 

CIM  CATEGORY:  RCR 

CONDITIONS:  Card  or  Magnetic  Tape  multi -card  messages 

only.  The  header  record  count  is  not  a 
numeric  field  between  0003  and  0500,  MTMS 
or  PLTS.  If  a  count  is  in  the  header, 
the  actual  number  of  records  (cards/ 


A.MPE  ACTION: 
ACTION  REQUIRED: 


P.RECEDENCE: 
COMMUNITY; 
.ADDRESSEES; 
CIM  CATEGORY 
CONDITIO.NS: 
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blocks)  received  does  not  match  the 
header  count;  if  MTMS  was  in  the  header 
and  a  count  in  the  trailer,  the  actual 
number  of  records  received  does  not  match 
the  trailer  card  count.  The  trailer  card 
record  field  is  not  MTMS,  or  a 
numeric  field. 

AM PE  ACTION:  Message  Rejected 

ACTION  REQUIRED;  Insure  card/record  count  is  correct. 

The  count  must  include  both  header 
and  trailer  cards  as  well  as  data 
cards.  Reprotect  to  all  addressees. 

EXCESSIVE  LENGTH  OF  ROUTING  INDICATOR  FIELD. 

TEXT: 

SVC  ACA129  YEXXACA1243  1231353 

EXCESSIVE  ROUTING  FIELD  REJ 

PRECEDENCE;  Message 

COMMUNITY;  Both 

ADDRESSEES;  SMRI,  SOP 

CIM  CATEGORY:  ERR 

CONDITIONS;  More  than  500  Routing  Indicators 

in  a  message.  No  End-of-Rou ting 
found  in  55  line  blocks  (56  including 
TI  line  if  applicable)  or  4400  data 
characters  including  header  fields. 
Erroneous  or  missing  EOR  symbol  or 
sequence . 

AMpe  ACTION:  Message  Rejected.  No  RI’s  are  protected. 

ACTION  REQUIRED:  Reprotect  message  to  all  addressees  by 

making  separate  transmissions  of  no 
more  than  500  RI's  each.  Ir  exceptional 
cases,  this  service  may  result  from  an 
erroneous  end-oE-r<>i  ting  ;  correct  and 
reprotect  after  insuring  that  actual  RI 
count  does  not  exceed  500. 

EXCESSIVE  LENGTH  OF  MESSAGE  (non-Critic) 


TEXT: 

UNCLAS  SVC  RUXXBCA1246  1231357 
EXCESS  MSG  LENGTH  REJ 
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PRECEDENCE;  Message 

CO^UM  UNITY;  Both 

ADDRESSEES;  SMRI,  SOP 

CIM  CATEGORY:  ELR 

COMiITlONS:  Message  exceeds  556  line  blocks  (556 

cards  or  54  ,  4  80  characters)  from  a 
Mode  I  or  Mode  V.  Message 

exceeds  125  line  blocks  (10,000 
characters)  from  a  Mode  II. 

Mode  II  channel  is  running  out  of 
crypto  synchronization  ("jumped  set"). 
AMPE  ACTION;  Message  rejected.  No  part  of  message 

is  protected. 

ACTION  REQUIRED:  If  message  exceeds  maximum  length, 

separate  message  into  sections  and 
reprotect  to  all  addressees.  For  Mode 
II  channels,  if  the  cited  message  does 
not  exceed  the  maximum  length,  insure 
proper  restoral  of  the  transmission 
path  or  crypto  synchronization.  Note 
that  messages  following  the  cited 
message  may  also  require  reprotection; 
if  so,  additional  AMpE  service  action 
(ZFX)  will  indicate  the  CSN's  requiring 
reprotection. 

INPUT  HIATUS  IN  MID  MESSAGE  (Non-Critic) 

TEST: 

SVC  ACA132  YEXXACA1247  1231359 
NO  EOM  RCVD  REJ 

PRECEDENCE:  Message 

COf-IMUNITY:  Both 

ADDRESSEES:  SMRI,  SOP 

CIM  CATEGORY:  None 

CONDITIONS:  No  data  has  been  received  by  the  AMPE  for 

approximately  a  3-minute  period  in  mid¬ 
message  . 

AMPE  ACTION:  Message  Rejected. 

ACTION  REQUIRED:  Insure  that  EOM  sequence  is  valid,  and 

that  there  has  been  no  equipment  mal¬ 
function.  Correct  as  necessary  and 
reprotect  to  all  addressees. 


'  *  ”  W  -  k.  I 


-  •  N'O  V-\LID  EOM  FOU^'D  IN  MESSAGE  WITH  AN  ETX  SLOCK  FRAMING 
CHARACTER 


UNCLAS  RUXXBCA12-4  8  12314  02 
IMVALID  ECK  REJ 


PRECEDENCE: 
COMMUNITY: 
ADDRESSEES: 
CIM  CATEGORY: 
CONDITIONS: 


AM PE  ACTION: 
ACTION  REQUIRED: 


Message 

Both 

SMRI,  SOP 
EMR 

An  ETX  franie  l  'jlook  '-las  been  found 
without  an  EOM  sequence  appropriate  to 
the  message  type.  This  condition  can 
result  only  from  terminal  equipment  or 
software  malfunction  on  Mode  I,  or  AMPE 
equipment  or  software  error  on  Mode  II 
and  Mode  V  channels. 

Message  Rejected. 

Reprotect  message  to  all  addressees. 

If  condition  is  repeated,  take  steps 
to  locate  equipment  problem.  Mode  Il/V 
users  should  contact  the  AMPE  to  report 
the  condition  and  request  assistance. 


12.  INVALID  CONTROL  CHARACTER  SEQUENCE  (Mode  V  Only) 


TEXT; 

UNCLAS  SVC  AVA132  RUXXAVA1322  1231407 
INVALID  CONTROL  CHARACTER  SEQUENCE  RECEIVED 
REPROTECT  TO  ALL  ADDRESSEES 


PRECEDENCE: 
COMMUNITY: 
ADDRESSEES: 
CIM  CATEGORY: 
CONDITIONS: 


Message 

Both 

aiRi,  sop 

None 

Mode  V  two-character  control  sequence 
in  error,  possibility  exists  that  a 
control  character  may  be  mistaken  for 
data  and  text  corrupted.  Can  only  result 
from  Mode  V  Control  Unit  malfunction. 
Reject  Message 

Reprotect  message.  Take  necessary  steps 
to  correct  equipment  problem. 


AMPE  ACTION: 
ACTION  REQUIRED: 


5USPSGTSD  STRAGGLER  (Y-Conmunity  or  Low  Precedence 
R-Corraunity ) 


TEXT: 

'JNCLAS  SVC  RUXXBCA1327  1231412 
SUSPECTED  STRAGGLER  REJ 


COr-C-l  UNITY: 
ADDRESSEES: 
CIM  CATEGORY: 
CONDITIONS: 


I.-medi  ate 
Both 

SMRI,  SOP 
SSR 

An  actual  straggler,  i.e.,  a  second 
message  or  portion  of  a  message  has 
been  sent  in  the  same  transmission  as 
the  cited  message.  If  this  is  not  the 
case,  other  errors  may  depend  on  the 
format  and  medium  of  the  cited  message 
as  follows: 

JANAP  Format  Teletypewriter  Input-Trailer 
Station  Serial  Number  (TSSN)  is  not 
present;  TSSN  sentinel  (#)  is  not 
present;  TSSN  does  not  match  Header  SSN; 

TSSN  and  sentinel  present  but  not  within 
23-character  range  of  EOMS. 

JANAP  Format  Card/Magnetic  Tape 
Input -Trailer  card  SSN 
missing,  raispositioned ,  or  does  not 
match  HSSN. 

ACP  Format,  R-Community  -  Sentinel  (4) 
missing  from  FL3  or  FL15;  serial  numbers 
do  not  match;  TSSN  not  within  proper 
range  of  EOMS. 

ACP  Format,  Y-Community  -  TSSN  sentinel 
missing;  TSSN  and  HSSN  do  not  match; 

TSSN  missing.  (A  missing  HSSN  (FL3) 
sentinel  results  in  rejection  for 
"INVALID  HEADER");  TSSN  not  within  proper 
range  of  EOMS. 

Exceptions  are  made  for  - 

(1)  High  Precedence  R-Community  (see 
Number  14  below) 

(2)  Critic  (No  validation  is  performed 
past  the  Critic  sequence) 

The  CRITIC  exception  (2)  is  "silent" 

The  message  is  accepted  and  no  ser'/ice  is  sent 


Message  Rejected. 

correct  header  and/or  trailer  station 
serial  numbers  as  necessary  and  repro¬ 
tect  to  all  addresses.  If  a  straggler 
is  actually  present,  insure  protection 
of  bot.h  messages  by  corrections  or 
service  action  as  necessary. 

14.  SUSPECTED  STRAGGLER  (High  precedence  R-Community) 

TEXT: 

UNCLAS  SVC  RUXXBCA1328  1231417 
HIGH  PREC  MESSAGE  ACCEPTED 
REPROTECT  SUSPECTED  STRAGGLER 

PRECEDENCE:  Immediate 

COMMUNITY:  R 

ADDRESSEES:  SMRI,  SOP 

CIM  CATEGORY:  None 

CO^ITIONS:  A  high-precedence  (ECP  or  Flash)  R- 

Community  message  has  been  accepted 

with  straggler  errors.  There  may  or 
may  not  be  an  actual  straggler,  i.e., 
a  second  message  or  portion  of  a  message 
sent  in  the  same  transmission  as  the 
cited  high-precedence  message. 

AMPE  ACTION:  Message  Accepted 

ACTION  REQUIRED:  Insure  reprotection  as  suspected  dupli¬ 

cate  of  any  actual  straggler.  No 
further  action  is  re<5uired  if  service 
message  is  result  of  straggler  number 
or  sentinel  error  in  the  cited  high- 
precedence  message  itself. 

15.  INVALID  CHANNEL  DESIGNATOR  CHANNEL  IDENTIFIER  (TI  Users 
Only) 

TEXT: 

UNCLAS  SVC  RUXXABA1322  1231419 

INVALID  CD  EXPECTED  ABA123  RCVD  BBA123  REJ (or  ACC) 


AMPE  ACTION: 
ACTION  REQUIRED: 


•  PRECEDENCE:  Message 

COMMUNITY:  Both 

.  ■  ADDRESSEES:  SMRI,  SO? 


CIM  CATEG^^:- 
CONDITIONS: 


:o 

channel  identifier  in  TI  line  was 
found  in  error.  The  expected  CD  and 
CSN  are  extracted  from  the  ASC  tables; 
the  received  CD  and  CSN  are  quoted  as 
r  ece  ived . 

AMPE  ACTION:  Y-Community  messaqes  are  rejected. 

(Critic  messages  are  accepted  with  CD 
error  but  no  service  message  is  sent.) 
R-Community  ECP  and  Flash  messages  are 
accepted  ("ACC")  if  there  are  no  other 
error  conditions;  all  others  are 
rejected . 

ACTION  REQJIRED;  If  massage  was  rejected  ("REJ"),  correct 

channel  identifier  and  reprotect  message; 
if  message  was  accepted  ("ACC")/  message 
need  not  be  reprotected.  In  either  case, 
terminals  using  a  Transmission  Identifier 
Line  generator  should  take  action  to 
correct  a  possible  equipment  malfunction. 

REMARKS:  Since  this  massage  concerns  the  CD-CSN, 

no  CD-CSN  is  cited  in  the  SVC  line. 

invalid  CH ANT^_EL  sequence  number  (TI  Users  Only) 

TEXT: 

UNCLAS  SVC  RUXXABA1323  1231419 

INVALID  CSN  EXPECTED  ABA127  RCVD  ABA133  ACC 

PRECEDENCE:  Message 

COMMUNITY:  Both 

ADDRESSEES:  SMRI,  SOP 

CIM  CATEGORY:  None 

CONDITIONS;  Channel  sejueno?  lunber  in  TI  line  did 

not  match  that  expected.  The  expected 

CD  and  CSN  are  extracted  from  the  AMPE 

table.?;  the  received  CD  and  CSN  are 
juoted  as  received.  Not  applicable  to 
Critic  messages.  This  message  may  also 
be  sent  if  an  AMPE  program  reload 
required  resetting  of  input  CSN's. 

If  this  is  the  case,  the  expected 
CSN  will  be  001. 


AM PE  ACTION: 


Message  accepted  vith  any  CSN  error 
other  than  a  duplicate  of  the  last 
accepted  (see  next  example).  If  the 
CSN  is  non-numeric,  it  is  accepted  as  if 
it  were  the  one  expected  and  the  AM?3 
counter  is  incremented.  If  the  CSN  is 
numeric,  it  is  accepted  and  the  AMPE 
counter  set  to  next  expect  one  number 
higher  . 

ACTION  REQUIRED;  The  message  was  accepted  therefore 

reprotection  is  not  required. 

If  accepted  CSN  is  numeric, 
it  is  suggested  terminal  continue  in 
that  range  if  possible  and  reprotect 
messages  associated  with  any  missing 
CSN's  as  indicated  by  CSN  range 
message  (ZFX)  which  will  accompany 
this  service  message.  Terminals  using 
a  Transmission  Identifier  Line  Generator 
should  take  action  to  correct  equipment 
malfunction  if  necessary. 

REMARKS:  Since  this  message  concerns  the  CD-CSN, 

no  CD-CSN  is  cited  in  the  SVC  line. 

17 .  CHANNEL  SEQUENCE  NUMBER  DUPLICATE  OF  LAST  CSN  ACCEPTED 

( T I  Users  Only) 

TEXT 

UNCLAS  SVC  RUXXABA1324  1231423 

DUPE  CSN  EXPECTED  ABA135  RCVD  ABA134  REJ  (or  ACC) 


PRECEDENCE: 
COMMUNITY: 
ADDRESSEES; 
CIM  CATEGORY 
CONDITIONS: 


Message 

Both 

SMRI,  SOP 
CNR 

Channel  Sequence  Number  in  TI  line  is 
identical  to  that  last  accepted.  The 
expected  CD-CSN  are  from  the  ASC 
tables.  The  received  CD-CSN  are  quoted 
as  received;  the  received  CSN  will 
always  be  one  less  than  that  expected. 
Not  applicable  to  Critic  messajas. 


13  . 


AMPE  ACTION:  R-Community  high  precedence  (ECP  and 

Flash)  me33age';  are  accepted;  ’/-Community 
Critic  messages  are  accepted  with  a 
duplicate  CSN,  bat  this  service  message 
is  not  sent.  All  othe'  na  usages  are 
r  e  jected . 

ACTION  REQUIRED:  If  cited  message  was  accepted,  terminal 

may  co.atiaie  i-i  oh  is  CSN  range.  No  CSN 
range  (ZFX)  message  is  generated  under 
the  duplicate  CSN  condition.  Terminals 
using  a  Transmission  identifier  Line 
Generator  should  take  action  to  correct 
equipment  malfunction  if  necessary.  If 
message  was  rejected,  insure  reprotection 
of  the  message  to  all  addressees.  The 
expected  CSN  cited  remains  the  next 
expected . 

CHANNEL  SEQUENCE  NUMBER (S)  MISSING  fTI  Users  Only) 


TEXT: 

UNCLAS  SVC  (this  line  not  in  Y-Comm  message) 
IFX  A8A123  THRU  ABA132 


RRHCSDENCE: 
COMMUNITY: 
ADDRESSEES: 
CIM  CATEGORY 
CONDITIONS: 


immedia  te 
Both 

SMRI,  SOP 
None 

The  AMPE  has  detected  an  "open  number" 
condition,  i.e.,  a  transmission  has 
been  received  with  a  CSN  higher  than 
the  next  expected.  Because  of  CSN 
"rollover",  a  lower  CSN  will  be  inter¬ 
preted  as  a  higher  one,  e.g.,  CSN's 
received  in  the  order  423,  424,  420, 
will  cause  generation  of  a  service 
message  citing  425  through  419  as  ZFX. 
Where  only  one  CSN,  148  for  example,  is 
missing,  the  message  cites  "ZFX  ABA148 
THRU  A3A148".  The  cited  range  may 
include  transmissions  rejected  for  other 
reasons.  This  message  may  also  be  sent 
if  a  program  reload  at  the  AMPE  ra<iuirel 
resetting  CSN's  to  zero.  if  th  i  ?  i-:  f  ■ 
case,  the  first  number  cited  will  be  001. 
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••V-IPE  ACTION; 


The  last  CSN  accepted  becomes  one  higher 
tiian  the  second  cited.  The  next  expected 
Is  one  more  higher.  In  the  examples 
above,  terminal  RUXXA3A  sent  ABA127 ,  then 
.ABA133 .  The  latter  was  accepted,  and  the 
terminal  advised  that  ABAl2 8-132  were 
open  numbers.  The  next  expected  is  134. 

ACTION  REQUIRED:  Rep;o:;'  -  --p-  Implicate  any 

message  transmission  made  under  the 
CSN(s)  cited.  Terminals  using  a  Trans¬ 
mission  Identifier  Line  Generator  (TIG) 
should  ta'<e  action  to  correct  equipment 
malfunction  if  necessary. 


TNO  CONSECUTIVE  SOM  SEQUENCES  RECEIVED  WITHOUT INTER¬ 
VENING  EOM  (Mode  II,/'/  Only) 


riXT: 

?/:  3UXXABA1346  1231426 

WO  CO  NSEC  SOMS  REJ 


PRECEDENCE:  (First)  Message:  immediate  if  no 

message . 

COMMUNITY:  Both 

ADDRESSEES:  SMRI,  SOP 

CIM  CATEGORY:  TSR 

CONDITIONS:  The  AMPE  has  recaiaed  two  consecutive 

s tar t-of-message  (ZCZC)  sequences 
without  an  intervening  end-of-message 
sequence.  The  message  cited  is 
incomplete.  A  second  message  may  or 
may  not  be  involved. 

AMpE  ACTION:  The  first  transmission  is  rejected. 

An  excaption  i Z  v.  \  r  ^c.ign  ix^d 
Iritic,  but  in  that  case,  no  service 
message  is  sent.  If  a  second 
message  is  involved,  it  is  accepted, 
barring  other  errors,  on  a  Mode 
II  channel;  it  is  rejected  on  Mode  I  and 
V.  If  no  first  message  is  involved  and 
there  are  merely  two  SOM's  ahead  of  a 
message,  the  precedence  of  the  service 
is  immediate,  and  the  SvC  line  may  con¬ 
tain  irrelevant  data,  such  as  X's  or 
spaces.  The  next  expected  CSN  is  one 
higher  than  that  associated  with  the 
first  SOM. 
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ACTION  REQUIRED: 


Insure  that  no  SOM  sequence  is  actually 
present  in  cited  message;  reprotect 
cited  message  to  all  addressees.  Termi¬ 
nals  using  a  Transmission  Identifier 
Line  Generator  should  take  action  to 
correct  any  equipment  malfunction. 

2 0 .  QIANNEL  CONTINUITY  VERIFICATION _ (Mode  II  or  Specially 
Classmarked  Y-Community  Channels  Only) 


TEXT; 

UNCLAS  SVC  ZID  ABA142 


PRECEDENCE 

COMMUNITY: 

ADDRESSEE: 


CIM  CATEGORY: 
CONDITIONS: 


AMPE  ACTION: 


ACTION  REQUIRED: 


Pr  ior  i  ty 
Both 

SMRI  (In  the  case  of  specially  class- 
marked  Y-Community  channels,  a  special 
RI  is  used) 

None 

No  traffic  has  been  received  by  the  AMPE 
for  a  period  of  30  minutes.  For 
specially  designated  Y-Community 
channels,  the  interval  is  reduced  to 
15  minutes. 

The  message  is  repeated  at  30 
minute  intervals  so  long  as  no  traffic 
is  received. 

If  station  records  shew  that  the  cited 
eSN  is  the  last  transmitted ,  no  further 
action  is  necessary.  If  station  records 
not  show  that  the  cited  CSN  is  the  last 
transmitted,  the  terminal  station  must 
establish  contact  with  the  AMPE  to 
determine  traffic  status  and,  when 
channel  continuity  has  been  restored, 
to  reprotect  the  message  (s)  associated 
with  any  missing  CSN(s). 


21.  INVALID  ROUTING  INDICATORS 


TEXT: 

UNCLAS  SVC  RUXXBCA1278  1231245 
INVALID  ROUTING  REPROTECT  TO: 

RUXXBBA-INV  RUXXALA-SEC  RUXXFMA-LMF  RUXXLLA-INV 
RUXXJJA-INV  RBFBCS-TRC  RUXXJBA-SRC 
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PRECEDrniC^: 

COMT-iCNirY: 

ADDRESSEES; 


CIM  CATEGORY; 
CONDITIONS; 


AMPE  ACTION: 


Mess a  ge 
Bo  th 

SMRI;  SOP  of  original  (entry)  AMPE. 

RIR  (each  invalid  RI  is  counted  as  a 
separata  violation). 

The  cited  niessage  cannot  be  delivered  to 
the  listed  RI(s)  for  the  reason (s)  given. 
The  message  is  protected  to  other  RI(s). 

The  codes  and  the  community  to  which 
they  are  applicable  are  as  follows: 

INV  -  The  Rl  does  not  appear  in  the  AMPE 
routing  tables  (R  and  V) 

SEC  -  Message  basic  security  classifica¬ 
tion  exceeds  the  level  authorised 
for  the  addressee.  (R) 

IldF  -  The  addressee  terminal  equipment 
cannot  accept  a  message  in  this 
medium  and  message  exchange  is 
prohibited . 

TRC  -  The  RI  listed  is  not  val:  dated 

by  a  proper  Transmission  Release 
Code  or  the  addressee  cannot 
accept  ALPS  traffic  (R). 

SRC  -  The  addressee  cannot  accept  a 
message  of  the  Special 
Handling  Designator  of  the  cited 
message. (R) 

TCC  -  The  addressee  cannot  accept  a 
message  containing  the  Trans¬ 
mission  Control  Code  of  the 
cited  messag-j  (Y). 

MFE  -  The  message  is  of  data  pattern  and 

is  either  piloted  or  does  not  contain 
a  security  line  (FL4).  Delivery 
to  the  addressee  teletypewriter 
station  is  prohibited. 

The  message  is  protected  to  RI's  other 
than  those  cited.  Note  that  another 
AMPE  may  find  other  RI's  to  be  invalid 
and  there  may  be  other  services  on  the 
cited  message.  If  all  RI's  are  invalid, 
the  message  is  rejected  to  Mode  I  and 
Mode  V  terminals. 
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ACTION  REQUIRED:  Determine  the  correct  routing 

indicator  (s)  and  reprotect  only  to  tliose 
necessary.  There  is  no  separate  or 
distinct  message  indicating  that  all 
RI's  are  invalid  and  it  is  incumbent  on 
the  terminal  operator  to  insure  proper 
reprotection  of  the  message  to  all 
addressees  whose  RI's  were  found  invalid 
Because  more  than  one  service  message 
may  be  received  for  invalid  RI's  on  the 
same  message,  all  such  service  messages 
must  be  honored. 

REMARKS:  This  service  lists  5  RI's  per  line. 

HIGH-PRECEDENCE  MESSAGE  ACKNCWLEDGMENT  (R-Community  >tode  II 
all  Y-Commun ity  channels) 


TEXT: 

UNCLAS  SVC  R  2  ABA143  RUXXABA1438  1231527 


PRECEDENCE: 


COMMUNITY: 

ADDRESSEES: 

CIM  CATEGORY: 
CONDITIONS: 


AMPE  ACTION: 


immediate  for  acknowledgment  of  EC?  and 
Flash;  Flash  for  acknowledgment  of 
Cr i tic . 

Both 

SMRI;  Special  RI's  on  CRITIC 
Acknowledgment,  see  Remarks. 

None 

Transmitted  to  the  terminal  from  which 
the  high-precedence  message  was 
received.  Transmitted  at  EOM-IN  time 
for  ECP  and  Flash.  Transmitted  at  ECM- 
ACK  time  for  Critic,  i.e.,  transmission 
of  tnis  message  for  a  Critic  indicates 
the  original  AMPE  has  transmitted  the 
Critic,  not  merely  accepted  it  for 
tr  ansmiss  ion . 

Flash  or  ECP  message  accepted;  Critic 
message  transmitted  and  electrical 
acknowledgment  received.  A.MPE  accepts 
full  responsibility  for  the  message. 
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ACTION  REQUIRED: 


File  for  record  purposes.  If  no 
acknowledgment  is  received  on  trans¬ 
mission  of  a  h igh -precede nee  on  a  Y- 
Comm  channel  or  a  >Jod9  II  R-coiTum 
channel,  insure  circuit  continuity 
and  contact  the  AMPE  for  assistance. 

Re  protect  the  high  precedence  .message 
as  suspected  duplicate  a.nd/or  by  other 
-Teans  as  necessary. 

RZ.M.ARKS:  The  letter  "R"  stands  for  "received"; 

the  second  letter  is  the  precedence  of 
the  acknowledged  message,  W,  Y  or  Z. 

For  Critic  acknowledgment  only;  The 
OSRI  is  the  pre-stored  prime  channel 
RI.  If  the  terminal  uses  TI  lines, 
the  OSSN  is  the  CSN  with  a  leading 
zero,  if  the  terminal  does  not  use 
TI  lines,  the  OSSN  is  9999.  The  TOF 
is  t.he  SOH-IN  time,  not  the  time  the 
Critic  was  transmitted  onward  by  the 
AMPE-  the  transmission  time  is  the  TOF 
of  the  service  message  itself.  The 
CD-CSN,  if  any,  are  not  separately  cited. 
A  copy  of  this  message  is  also  sent 
to  NSA  and  to  DCA  at  immediate 
precedence . 

23.  PARTIAL  CRITIC  MESSAGE  RECEIVED 
TEXT: 

SVC  YEXXAyA0l23  1231446 
PARTIAL  WW  MESSAGE  RECEIVED 

PRECEDENCE:  Flash 

COMMUNITY:  Y 

ADDRESSEES;  SMRI,  SOP 

CIM  CATEGORY:  None 

CONDITIONS:  Generated  when  a  Critic  message  being 

received  experiences  an  input  hiatus  of 

approximately  60  seconds,  a  two  consecu¬ 
tive  SOM  condition,  or  is  over  75  line- 
blocks  (6000  characters)  in  length. 
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AMFE  ACTION: 


This  service,  like  the  high-precedence 
acknowledgtient  for  Critic  ("FW"),  is 
generated  when  the  original  AMPE  has 
trans.uitted  the  partial  Critic  and 
received  an  electrical  acknowledgment. 
ACTION  REQUIRED:  If  the  Critic  was  transmitted  incomplete, 

file  for  record  purposes.  If  a  complete 
message  was  transmitted,  take  action  to 
insure  circuit  continuity  and  retransmit 
message  or  reprotect  by  any  alternate 
means  in  accordance  with  station 
operating  instructions.  If  the  message 
is  over  75  line  blocks,  reprotect  entire 
message  by  separating  into  sections  or 
reprotect  the  portion  over  75  line  blocks 
as  directed  by  station  operating 
ins  tractions . 

RE'IARKS:  The  CD-CSN  are  not  separately  cited  in 

this  message.  The  OSRI  is  the  prime 
channel  (pre-stored)  RI  for  the  channel. 
The  OSSN  is  the  CSN  with  a  leading  0. 

If  the  channel  does  not  use  a  TI  line  the 
OSSN  is  9999.  The  TOP  is  SOH-IN  time, 
not  the  time  of  transmission  from  the 
AMPE,  which  is  indicated  by  the  TOP  of 
the  service  message  itself. 

24.  CRITIC  MESSAGE  PORWARDED 
TEXT: 

SVC  TEXXAYA  0122  1231442 
',vW  MESSAGE  FORWARDED 

PRECEDENCE:  Immediate 

COMMUNITY:  Y 

ADDRESSEES:  NSA,  DCAOC 

CIM  CATEGORY:  None 

CONDITIONS:  Generated  by  each  AMPE  handling  a  CRITIC 

message  at  the  time  the  electrical 
acknowledgment  is  received  for  a  trans¬ 
mitted  Critic. 

AMPE  ACTION:  Critic  message  transmitted  to  either 

destination  terminal  or  another  AMPE. 
ACTION  REQUIRED:  File  for  record  purposes;  other  handling 

in  accordance  with  current  operating 
procedures . 
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il ■'  nR  A 5  I 


rtliows  "tracking"  of  a  Critic  i::essage  by 
;,Sn  anc  DCm JC.  Aics  i;,  recccnizing  and 
CutTcCtino  any  trariSi.ri  i  wii  utaiays. 


nRTInL 


.  I  n-  .'hbaMbh  rUn.vrtKbtlU 


TEXT; 

SV:  VEXAiY-Gl.i  i23!^T6 
T-R-lr-L  RESE.-.CE  FCRaAREEj 


RL.,''r‘,Al\5 : 


inis  Scf'^icc  iiidssagc  pcrcains  tu  a 
partial  ^truncatea)  Critic.  All 
other  information  sliown  above  for  Critic 
Message  Fonvarced  applies  to  tnis  message 
also. 


26.  AITODIC  LIMITED  PRIVACY  SERVICE  (ALPS)  REPROTECT  MESSAGE 


TEXT; 

UhCLAS  SVC  RUXXBCA1332  1231450 
mMS-REPKOTECT  I’iESSMGE  TO; 

RUXXmSA  RUXXEBh  ruxxcba  RUXXCCA  RUXXODA  RUXXEEA  ruxxffa  ruxxgga 
RUXXHhrt 


PRECEDENCE: 
COMMUNITY; 
AuDRESSEES; 
CIM  CATEGORY; 
CONDITIONS; 


AMPE  ACTION: 
ACTION  REQUIRED; 


REMARKS ; 


Message 

Both 

SMRI;  SOP 
None 

Since  ALPS  message  text  is  not  recorded 
on  the  AnPE  history  record,  an  ALPS 
message  cannot  be  retransmitted  by  the 
mMFE  at  tne  request  of  an  aooressee  or 
recovered  after  an  AMPE  failure.  When 
retrieval/recovery  is  necessary,  this 
service  is  generated  to  the  message 
originator  listing  the  RI's  to  vniich 
retransmission  must  be  mace. 

No  further  action  is  taken  on  the  message 
after  generation  of  this  service. 
Retransmit  cited  message  as  suspected 
duplicate  to  all  listed  RI’s.  Note  that 
more  than  one  service  message  may  be 
received  for  the  cited  message;  all  must 
be  honored. 

The  OSRI  of  this  service  message  reads 
"RUXXCSR"  instead  of  "RUXXCSD".  There 
are  eight  RI's  to  a  line. 
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ALTER-NATS  ROUTING  INVOCATION  MESSAGE. 

TE  XT: 

UNCLAS  SVC 

TRAFFIC  IS  BEING  DI'/ERTED  TO  YOUR  STATION, 

PROTECT  TO: 

RUXX.A3  RUXX3C  RUXXCD  RU:«DE  RU:aEF 

RUXXFG  RUSSGH 

PRECEDENCE:  See  conditions  below 

COMMUNITY:  Both 

ADDRESSEE:  SMRI 

CIM  CATEGORY:  None 

CONDITIONS:  The  header  of  this  itessage  is  exactly 

like  that  of  a  normal  service  message. 

Its  precedence  is  normally  immediate, 
but  may  be  Flash  if  high-precedence 
traffic  will  be  subject  to  the 
diversion.  For  example,  if  all  traffic 
is  to  be  diverted,  the  notification 
message  will  be  Flash  precedence. 

The  notification  message  is  placed  at 
the  head  of  the  queue  by  precedence,  so 
that  it  will  precede  any  diverted 
tra  ff  ic . 

AMpe  ACTION:  Implementation  of  alternate  routing 

ACTION  REQUIRED:  Protect  diverted  traffic  in  accordance 

with  established  altroute  agreements 
and/or  local  procedures.  Note 
that  each  invocation  message  lists  only 
those  Rl 's  whose  traffic  is  now  being 
diverted.  The  terminal  remains  respon¬ 
sible  for  protection  of  traffic  to  Rl's 
listed  in  any  previous  alternate  route 
invocation  message  until  a  specific 
revocation  message  is  received. 

REMARKS:  Only  the  first  six  characters  of  diverted 

Rl's  are  given.  These  are  all  AUTODIN 
actually  routes  on.  The  seventh  Rl 
character,  if  present,  of  diverted 
traffic  may  be  any  alphabetic,  in  this 
message  and  the  following  one  there  are 
five  Rl's  to  a  line. 
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28.  Al~~irp.ate  itouting  Pavocation  Message  -  T.*ie  second  message 
tr  ansmi  t  wed  to  a  terminal  as  a  result  of  AMPE  alternate  routing 
activity  advises  that  traffic  for  certain  Rl's  will  no  longer 
be  diverted  to  the  terminal. 

mE  XT  < 

'J>;CL.AS  SVC 

TR.AFFIC  IS  NO  LONGE.R  BEING  DIVERTED  TO  YOUR  STATION  FOR; 

R'JXXBC  RU'XXCD  RUXXDE  RL’XXEE  RUXXFG 

PRECEDENCE:  immediate 

COMMUNITY:  Both 

ADDRESSEE:  SMRI 

CIM  CATEGORY:  None 

CONDITIONS:  See  above 

AMPE  ACTION:  Revocation  of  alternate  routing 

ACTION  REQUIRED:  Continue  to  protect  diverted  traffic  for 

any  Rl's  previously  listed  in  an 
invocation  message  but  not  listed  in 
this  message.  in  the  e.xamples,  the 
terminal  must  still  protect  for  RUXX.AB 
and  RUXXGH/  whose  altroutes  have  not 
been  revoked.  Any  traffic  subsequently 
received  for  Rl's  listed  in  this  message 
(because  traffic  was  on  the  AMPE  output 
queue  at  time  of  revocation)  may  be 
protected  either  in  accordance  with  WARP 
or  by  re-entry  into  AUTODiN,  as 
prescribed  by  local  procedures  and 
applicable  operating  instructions. 

29.  INVALID  FORMAT  LINE  12 

TEXT: 

UNCLAS  SVC:  RUXXBCA1327  1231412 

Inavlid  Format  Line  12  or  Security  Mismatch  -  REJ 

ACC 

Message 
Both 

^RI,  SOP 

The  security  in  format  line  12  is  not 
expanded  properly  cr  does  not  match 
security  in  format  line  2. 

AMPE  ACTION:  Reject  Message. 

ACTION  REQUIRED:  Correct  the  security  field  in  error  and 

reprotect  message  to  all  addressees, 
if  the  error  occurred  on  a  high  proce- 
dence  message  indicating  correct  security 
and  transmit  message  at  the  next  lower 
precedence  level. 


PRECEDENCE; 
COMMUNITY: 
ADDRESSEES: 
CIM  CATEGORY 
CONDITION: 
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30 .  AMPE  Reload  Message 


TEXT: 

2CR,  8LF 
UNCLAS  SVC 

RUXX  <V'1PE  RELOADED.  ANY  MESSAGES  PARTIALLY  RECEIVED 
IMMEDIATELY  PRIOR  TO  THIS  MESSAGE  WILL  BE  RETRANS-IITTED. 


PRECEDENCE: 

COMMUNITY; 

ADDRESSEES: 

CIM  CATEGORY; 
CONDITION: 

AMPE  ACTION: 

ACTION  REQUIRED; 


Flash 

Both 

All  connected  stations 
None 

Generated  when  an  AMPE  has  performed  a 
r  eload . 

This  service  message  is  the  first  message 
transmitted  to  each  channel  following  a  reload. 
Take  note  whether  preceding  message 
was  incomplete,  annotate  logs  and  handle  as  can 
celled  message  received. 
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INTRODUCTION 


1.0  Purpose.  This  section  specifies  the  multilevel  security  (MLS) 
requirements  for  the  Inter-Service/Agency  Automated  Message  Processing 
Exchange  (I-S/A  AMPE)  Program.  It  contains  the  system  security 
requirements  and  taskinys  to  ensure  certification  and  subsequent 
accreditation.  Furthermore,  it  provides  the  basis  for  developing  the 
Functional  System  Specification. 


1 . 1  Background 

1.1.1  The  I-S/A  AMPE  Program  is  ati  element  of  the  Integrated  Ab'T0DII<' 
System  Architecture  (lASA).  The  overall  objective  of  the  lASA  is  the 
design  of  a  coinmon-user  data  communications  system  for  the  Department  of 
Defense  (DoD).  The  I-S/A  AMPE  program  contributes  to  that  objective  by 
providing: 

a.  The  minimum  essential  functional  capabilities  and  features 
necessary  to  functionally  replace  the  existing  Service  and  Agency  base 
-level  Automated  Message  Processing  Exchanges  and  meet  validated  Service 
and  Agency  automated  telecommunications  requirements. 

b.  A  functional  replacement  for  the  current  AUTODIK  Switching 
Centers  (ASCs). 

c.  An  interface  for  the  AUTODIN  community  of  terminals  to  ttie 
Defense  Data  Network  (DDN)  using  Host-To-Host  Protection  (H^p)  devices 
(e.g.,  BLACKER  Program). 

d.  A  capability  to  consolidate  Defense  Special  Security 
Communications  System  (DSSCS)  and  General  Service  (GEN'SER) 
telecommunications  centers. 

1.1.2  When  initially  deployed,  separate  I-S/A  AMPEs  will  be  employed  for 
the  GEN'SER  or  "R"  community  and  the  DSSCS  or  "Y"  and  "Y/R"  community. 
(Note  that  "Y/R"  terminals  are  in  fact  "Y"  terminals  allowed  to  pass  "K" 
traffic  in  addition  to  their  normal  "Y"  traffic.)  Communications  between 
I-S/A  AMPEs  will  be  via  a  multilevel  secure  backbone  (i.e.,  tite  ASC 
network  or  the  Defense  Data  Network  with  BLACKER  Host-to-Host 
Protection).  Each  employment  of  the  I-S/A  AMPE  shall  oe  designeo  to  be 
certifiable  to  support  a  multilevel  secure  accreditation.  The  I-S/A  AMPE 
will  be  subjected  to  extensive  design  analyses,  testing,  and 
certification  leading  to  accreditation. 

1.2  General  Multilevel  Security  Objectives.  The  following  paragraphs 
provide  an  over v few  for  tlie  I-S/A  AMPE  security  measures.  The  reader 
should  consult  Section  10.0  of  the  FRD  as  well  as  tlie  "Trusted  Computer 
System  Evaluation  Criteria"  glossary  for  definition  of  terms. 

1.2.1  The  I-S/A  AMPE  is  to  be  designed  to  support  current  DoD  policies 
concerning  the  protection  of  classified  information.  The  policies  deal 
with  authorizations  to  access  information  based  on:  security  level 
clearances,  security  compartment  (category)  authorizations,  need-to-know, 
and  the  combination  of  security  classification  and  compartments  of 
information. 
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These  policies  are  contained  in  DoD  Regulation  5200. 1-R,  “Infonnation 
Security  Program  Regulation";  DoD  Directive  5200.28,  "Security 
Requirements  for  Automated  Data  Processing  (ADP)  Systems";  DoD  Directive 
5215.1,  "Computer  Security  Evaluation  Center",  Defense  Intelligence 
Agency  Manual  DIAM  50-4,  "(C)  Security  of  Compartmented  Computer 
Operations  (U)";  DoDD  C-5030.58,  "(C)  Consolidation  of  Telecommunications 
Centers  Involving  Defense  Special  Security  Communications  Systems  ana 
General  Services  Communications  (U)";  DoD  C-5030.58H,  "(C)  Defense 
Special  Security  Communications  Systems--Secur ity  Criteria  and 
Telecommunications  Guidance  (U)";  USSID  702, "(C)  Automatic  Data 
Processing  (ADP)  Systems  Security  (U)";  SM  36-76,  "(S)  Safeguarding  the 
SIC?(U)";  DCID  1/16,  "(C)  Security  of  Foreign  Intelligence  in  Automated 
Data  Processing  Systems  and  Networks (U)";  and  in  the  DCA 
"Inter-Service/Agency  Automated  Message  Processing  Exchange  (I-S/A  AMPE) 
Selected  Security  Architecture"  memoranduni, 

1.2.2  Messages  and  data  processed  by  the  I-S/A  AMPE  will  be  of  varying 
security  levels  and  security  compartinents  encompassing  the  full  range  of 
DoD  classifications,  including  unclassified.  Furthermore,  the  I-S/A  AMPE 
will  support  users  (i.e.,  subscribers,  subjects,  and  individuals)  having 
various  clearances  and  authorizations  which  span  a  range  for  which  an 
I-S/A  AMPE  has  been  accredited.  The  I-S/A  AMPE  is  to  be  certifiable  and 
accreditable  as  a  multilevel  secure  and  compartmenteu  mode 
telecommunications  system.  To  meet  these  accreditation  requirements,  the 
I-S/A  AMPE  system  must  have  computer  security,  reliability,  anu  integrity- 
features  to  ensure  that  the  I-S/A  AMPE  prevents: 

(a)  Deliberate  or  inadvertant  access  to  classified  material  by 
unauthorized  users  (i.e.,  subscribers  and  individuals), 

(b)  Unauthorized  manipulation  of  the  I-S/A  AMPE  and  its  associated 
peripheral  devices,  and 

(c)  Both  loss  of  system  integrity  and  loss  of  informatioii  integrity. 

1.2. 2.1  The  I-S/A  AMPE  must  provide  reliable  information  that  will  aid 
in  the  discovery  and  investigation  of:  (a)  Violations  or  attempted 
violations  of  DoD  Security  Policy;  (b)  Technical  attacks  against  the 
I-S/A  AMPE  oriented  towards  denial  of  service. 

1.2. 2. 2  The  I-S/A  AMPE  must  provide  isolation  mechanisms  complementary 
to  the  secure  operating  system  to  provide  the  protection  support 
necessary  to  meet  the  criteria  specified  in  this  document. 

1 .3  Design  Criteria. 

1.3.1  Trusted  Computing  Base  (TCB)  requirements  are  an  integral  part  of 
the  total  I-S/A  AMPE  solution  and  are  not  to  be  developed  independently 
from  other  requirements.  The  TCB  is  to  be  developed  along  with  the  ottier 
functional  requirements  of  the  I-S/A  AMPE  as  specified  in  the  I-S/A  AMPE 
Functional  Requirements  Description  (FkD).  Correspondence  shall  be  shown 
between  each  level  of  MIL-STD-490  A-,  b-,  and  C-Specif ications  as  the 
design  is  further  refined.  Complete  correspondence  from  the  security 
policies  down  to  the  Configuration  Item  (Cl),  Computer  Program 
Configuration  Item  (CPCI),  and  Computer  Program  Com,.onent  (CPC)  levels  of 
implementation  shall  be  demonstrated. 
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1.3.2  The  Class  Al  of  the  Trusted  Computer  System  Evaluation  Criteria 
requires  the  use  of  formal  methods  to  specify  and  verify  the  design  of 
the  TCB.  Formal  verification  begins  witn  the  development  of  a 
mathematical  model  implementing  the  DoD  security  policies.  A  Formal  Top 
Level  Specification  (FTLS)  shall  be  developed  and  verified  for  all 
elements  of  the  I-S/A  AMPE  system  that  implement  the  formal  security 
model.  The  FTLS  shall  be  written  using  a  government  approved  verifiable 
formal  specification  language  or  equivalent.  A  mapping  shall  be  ^jrovided 
between  the  High  Order  Language  implementation  of  the  TCB  and  the 
verified  FTLS. 

1.4  Section  30  Overview.  This  part  of  the  FRD  uses  the  following 
structure  to  divide  the  information  presented. 

a.  An  introduction  and  bibliography  of  referenced  documents  is 
presented  in  paragraphs  1  and  2. 

b.  Security  policy  is  stated  in  paragraph  3. 

c.  The  actual  functional  requirements  are  identified  in  parai,raph  4. 

d.  Paragraphs  5  through  12  define  the  contractor  taskings  required 
to  support  the  intensive  design  and  analysis. 


DCCUl'iENTS 


2.1  General.  Documents  identified  in  this  paragraph  are  binain^  on  the 
contractor  only  to  the  extent  specified  in  the  requirements  section  of 
this  document. 

2.2  DoD  Documents. 

AFI.'AG-5G  "(C-NOFOR:0  Red  and  Black  Engineering  and 

Installation  Criterions  (U)"  Mar  74 

AFf;AG-9A  "Using  NACSEM  Documents  and  TEMPEST 

Emanations  Limits" 

DIAM  50-4  "(C)  Security  of  Compartmented  Courputer 

Operations  (U)" 

DoCD  C-5030.58  "(C)  Consolidation  of  Telecomniunications 

Centers  Involving  Defense  Special 
Security  Communications  Systems  and 
General  Service  Communications  (U)" 

DoD  C-5030.58M  "(C)  Defense  Special  Security 

Communications  Systems  --  Security 
Criteria  and  Telecommunications  Guidance 
(U)" 

DoCR  5200. 1-R  "Information  Security  Program  Regulation" 

DoDD  5200.28  "Security  Requirements  for  Automateu  Data 

Processing  (ADP)  Systems" 

DoCD  5215.1  "Computer  Security  Evaluation  Center" 

JCS  SM  35-75  "(S)  Safeguarding  the  SICP(U)" 

JCS  Pub  22  "WWMCCS  ADP  System  Security,  Jan  8U" 

KIL-!iDBK  232  "Red/Black  Engineering  Installation 

Guidelines",  14  Rov  72 

MIL-STD-4o3  "Configuration  Management  Practices  for 

Systems,  Equipment,  Munitions,  and 
Computer  Programs" 

MIL-STD-490  "Specification  Practices" 

MIL-STD-881A  "Work  Breakdown  Structure" 

MIL-STD-1521C  "Technical  Reviews  and  Audit  for  Systems, 

Equipment,  and  Computer  Programs" 

NACSIM  5100A  "(C)  Compromising  Emanations  Laboratory 

Test  Requirements,  Electromagnetics  (U;, 
Jul  81" 
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NACSEM  5112 


"(S-NOFORN)  Nonstop  Evaluation  Techniques 
{U}"  Apr  75 


NACSEM  5201 
NACSEM  5203 

USSID  702 
DCID  1/16 


CSC-STD-001-S3 
0MB  A71-TM1 


"(S)  Comproiiiisintj  Emanations  Design 
Handbook  (U)" 

"(C)  Guidelines  for  Facility  Design  and 
Red/Black  Installation  (U)" 

"(C)  Automatic  Data  Processing  (ADP) 
Systems  Security  (U)",  24  Sep  80 

"(C)  Security  of  Foreign  Intelligence  in 
Automated  Data  Processing  Systems  and 
Networks",  Jun  78 

"(C)  Technical  Development  Plan  for 
Inter-Host  Multilevel  Network  Security 
Program  (U)",  Computer  Security  Center, 
18  Nov  32 

"Trusted  Computer  Systein  Evaluation 
Criteria",  15  Aug  83 

"Security  of  Federal  Automated 
Information  System" 


SECURITY  POLICY 


3.1  DoP  Security  Policy.  The  DoD  security  requirements  are  stated  in 
DoD  InTorrnation  Security  Program  Regulation  5200. 1-R.  Additional 
guidance  for  security  of  Federal  automated  information  systems  is  found 
in  0MB  Circular  A-71.  This  Circular  makes  the  head  of  each  executive 
branch,  department  and  agency  responsible  "for  the  establishment  of 
physical,  administrative  and  technical  safeguards  required  to  adequately 
protect  personal,  proprietary  or  other  sensitive  data  not  subject  to 
national  security  regulations,  as  well  as  national  security  data."  From 
these  fundamental  regulations  and  the  objectives  (e.g.,  protection  from 
unauthorized  disclosure  (compromise),  denial  of  service,  or  unauthorized 
alteration)  specified  in  para^jraph  1.2  of  this  section  of  the  FRD  are 
derived  the  following  five  basic  security  policy  requirements  wnich  must 
be  met  by  the  TCB. 

3.1.1  Marking .  The  I-S/A  AMPE  shall  maintain  the  integrity  of  security 
classification  and  other  sensitivity  marking  labels  and  their  unambiguous 
association  with  all  information  processed  by  the  I-S/A  AMPE.  The  I-S/A 
AMPE  shall  ensure  that  classified  or  other  sensitive  information  is 
accurately  marked  witfi  the  received  classification  and  other  sensitivity 
labels  when  stored  and  when  included  in  output  from  the  system. 

3.1.2  Mandatory  Security  ControK  The  I-S/A  AMPE  shall  enforce  the 
foririal  system  of  information  control  inherent  in  the  security 
classification  designation  and  special  handling  restriction  set(s) 
associated  with  the  information  and  the  clearance  set(s)  associated  witn 
the  subscribers,  subjects,  or  individuals  who  may  directly  or  indirectly 
request  access  to  the  information.  Specifically,  no  subscriber,  subject, 
or  individual  shall  have  access  to  classified  information  or  material 
unless  that  subscriber,  subject,  or  individual  has  been  determined  to 
possess  the  requisite  security  clearance  and  such  access  is  necessary  for 
the  performance  of  official  duties.  Community  separation  shall  always  be 
enforced  by  the  I-S/A  AMPE. 

3.1.3  Discretionary  Security.  The  I-S/A  AMPE  shall  enforce  need-to-know 
access  restrictions  placed  on  inforiijation  as  determined  by  the  originator 
of  a  message,  the  owner  of  information,  or  the  Security  Administrator. 
Keed-to-know  restrictions  are  based  on  Routing  Indicators  and  plain 
Language  Addresses  and  the  associated  delivery  attributes  explicitly 
stated  in  the  Attribute  Table(s)  and  in  the  Access  Control  Mechanism. 

3.1.4  Accountabi 1 ity.  The  I-S/A  AMPE  shall  identify,  authenticate,  and 
record  the  identity  of  subscribers,  operating  positions,  operators,  and 
system  administrators  and  validate  their  authorization  for  access  to 
services  and  information.  The  I-S/A  AMPE  shall  provide  the  capability 
for  recording  the  individual  accountability  of  a  person  in  question  to 
which  access  was  granted  or  denied,  the  security  level  at  which  the 
request  was  made,  the  type  of  access  granted,  and  the  date  and  time-stanip 
of  the  access  request.  Additionally,  the  I-S/A  AMPE  shall  proviae  the 
capability  for  authorized  agents  to  securely  access  and  evaluate  the 
above  audit  information. 


30-3-1 


3.1.5  Continuous  Protection  of  the  I-S/A  Al^PE  Systeiii.  Classified 
information  and  material  in  the  I-S/A  AMPE  shall  be  safe-guardea  by  the 
continuous  employment  of  protective  features  in  the  system's  hardware  and 
software  design  and  configuration  control  and  by  other  appropriate 
administrative,  physical,  personnel,  and  communications  security 
controls.  Since  mechanisms  within  the  I-S/A  AMPE  will  be  responsible  for 
the  protection  of  the  classified  informatvon  entrusted  to  the  I-S/A  AMPE 
for  processing,  the  I-S/A  AHPE  system  shall  be  protected  by  appro^^riate 
physical  means,  procedures,  and  configuration  control.  Software 
mechanisms  shall  be  protected  beginning  with  their  initial  design  and 
continuing  throughout  the  life  of  the  program.  Hardware  mechanisms  shall 
be  protected  beginning  with  government  approval  of  the  C-level 
specification  (i.e..  Critical  Design  Review)  and  continuing  throughout 
the  life  of  the  program.  The  I-S/A  AMPE  protection  shall  be  implemented 
so  that  the  Government  can  maintain  its  administration.  This  rigorous 
and  continuous  protection  shall  include  recording  all  changes  and 
attempted  changes  to  the  I-S/A  AMPE. 

3.2  Evaluation  Criteria.  Trusted  Computer  System  Evaluation  Criteria 
are  a  vital  part  of  the  overall  I-S/A  AMPE  system  security  evaluation 
process  as  specified  in  DoDD  5215.1.  DoD  Computer  Security  Evaluation 
Center  will  use  the  Functional  Requirements  Description  and  the  Class  Al 
Trusted  Computer  System  Evaluation  Criteria  as  the  basis  for  evaluation 
criteria  for  computer  security  aspects  of  the  I-S/A  AMPE. 

3.3  Independent  Verification  and  Validation.  The  Government  reserves 
the  rTgTit  to  have  an  inde^jencient  contractor (s)  attend  all  contractor  or 
Government  held  meetings  and  reviews. 

3.4  Denial  of  Service.  During  the  development,  testing,  anu 

i  mp  1  ernen  ta  1 1  on  of  I  -  3/ A  AMPE,  the  avai  1  ibi  1  ity,  reliability,  and  recovery 
features  of  the  I-S/A  AMPE  which  impact  on  authorized  access  to 
information  or  service,  will  be  demonstrated  and  certified  as  reducing 
the  denial  of  service  threats  to  an  acceptable  level  of  risk. 
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4.1.1  The  software  and  data  shall  be  modularized  and  identified  in  a  way 
that  makes  effective  use  of  the  protection  features  provided  by  the 
Trusted  Computing  Base. 

4.1.2  Subject  and  object  creation,  name  association,  and  protection 
attribute  ^  .signment  or  modification  shall  always  take  place  under  TCB 
control.  .n  object  is  defined  as  a  passive  entity  tliat  contains  or 
receives  information.  Software  created  entities  such  as  buffers, 
records,  files,  formal  messages,  programs  and  directories  as  well  as 
hardware  resources  such  as  memory  blocks,  disk  tracks,  tapes,  and 
peripheral  devices  that  contain  the  data  are  considered  objects.  A 
subject  is  defined  as  an  active  entity,  generally  in  the  forii.  of  a 
person,  process,  or  device  that  causes  information  to  flow  among  objects 
or  changes  the  system  state. 

4.2  Security  Labeling 

4.2.1  Every  subject  and  object  shall  have  an  associated  label  that 
indicates  security  related  attributes.  These  labels  will  provide  the 
basis  for  the  TCB  to  grant  access  to  objects  by  subjects  in  accordance 
with  the  defined  security  policy. 

4.2.2  At  a  minimum,  label  information  shall  include  security 
classifications  and  security  compartments,  which  collectively  are  termed 
security  label.  In  addition,  security  labels  for  objects  shall  include 
discretionary  access  control  attributes.  The  TCB  shall  provide  for  a 
minimum  of  sixteen  hierarchically  ordered  security  classifications. 

These  sixteen  ordered  classifications  shall  include  the  ordered  set  of 
classifications:  UKCLASSIFIED,  COKFIDENTIAL,  SECRET  and  TOP  SECRET.  Tne 
systeiii  shall  also  provide  for  a  minimum  of  255  non-hierarchial 
categories.  The  design  shall  not  preclude  expansion  to  at  least  512 
non-hierarchical  categories. 

4.2.3  The  TCB  shall  establish,  associate,  and  preserve  against 
alteration,  a  security  label  for  each  subject  and  for  each  object.  Label 
association  shall  apply  to  the  display  of  information  as  well  as  to 
manipulation  within  the  TCB  established  security  perimeter.  The  TCB 
shall  maintain  the  integrity  of  the  security  label (s).  The  TCB  shall 
ensure  that  all  displayed  information  is  clearly  labeled  with  respect  to 
security  classification,  category,  and  other  optionally  indicated  access 
restrictions.  The  TCB  shall  ensure  display  information  is  restricted  to 
display  devices  authorized  access  to  the  information. 

4.2.4  Object  labeling  shall  be  satisfied  at  the  message  level  and 
support  the  requirements  for  telecommunications  processing;  statistics 
development;  generation,  editing  and  preparation  of  messages;  and 
security  audit  actions.  The  TCB  shall  prevent  unauthorized 
reclassification  of  information  and  the  unauthorized  association  of  a 
label  with  information. 

4.2.5  The  security  label  parameters  of  an  access  line  shall  be 
changeable  only  under  the  control  of  the  TCB  and  only  with  the  approval 
of  the  Security  Administrator,  and  shall  be  audited. 


4.3  Trusted  Access  Control. 

4.3.1  Access  of  objects  by  subjects  shall  be  mediated  by  an  access 
control  mechanism  within  the  TCB  that  has  been  certified  as  enforcing  the 
Mandatory  and  Discretionary  Access  Control  requirements  of  tnis 
document.  The  TCB  access  control  mechanism  shall  enforce  the  following 
rules: 


4. 3. 1.1  A  subject  must  have  satisfied  Mandatory  and  Discretionary  Access 
Control  requirements  for  an  object  or  the  access  shall  neither  be 
authorized  nor  permitted. 

4. 3. 1.2  The  security  level  of  subjects  to  be  used  during  a  session  (the 
session  security  level)  shall  be  determined  by  the  TCB  before  access 
shall  be  authorized.  The  session  security  level  of  a  subject  shall  be 
verified  by  the  TCB  to  be  within  the  accredited  security  authorizations 
for  the  subject.  Changes  to  the  session  security  level  of  each  subject 
shall  be  mediated  by  the  TCB  and  shall  require  the  initiation  of  a  new 
session. 

4. 3. 1.3  A  subject  shall  be  allowed  read  access  to  an  object  only  if  the 

security  classification  of  the  subject  is  greater  than  or  equal  to  the 
security  classification  of  the  object  and  the  collection  of  the  security 

compartments  of  the  object  is  included  in  the  collection  of  the  security 

compartments  of  the  subject.  Community  separation  shall  be  maintained. 

4. 3. 1.4  A  subject  shall  be  allowed  write  access  to  an  object  only  if  the 

security  classification  of  the  subject  is  less  than  or  equal  to  the 

security  classification  of  the  object  and  the  collection  of  the  security 

compartiiients  of  the  subject  is  included  in  the  collection  of  ttie  security 
compartments  of  the  object.  Community  separation  shall  be  maintained. 

4.3.2  The  physical  media  containing  the  TCB  shall  be  protected  against 
unauthorized  modification  and  shall  be  placed  under  strict  configuration 
control.  The  TCB  shall  include  mechanisms  that  protect  it  from 
unauthorized  modification.  The  TCB  shall  be  self  protecting  to  prevent 
unauthorized  changes.  Each  attempted  modification  to  the  TCB  shall  be 
rejected,  an  audit  record  of  the  attempt  shall  be  made,  and  the  Security 
Administrator  Position  shall  be  immediately  advised  of  any  attempt  to 
modify  the  TCB. 

4.4  Security  Label  Change. 

4.4.1  The  TCB  shall  include  a  privileged  trusted  process  tiiat  allows 
change  of  security  labels  of  system  resources  under  explicitly  defined 
carefully  controlled  conditions. 

4.4.2  Only  the  change  process{es)  shall  have  access  to  an  object  while 
that  object's  security  attributes  are  being  changed. 

4.4.3  Resources  whose  security  labels  are  being  changed  snail  be 
inaccessible  to  all  but  the  change  process  until  the  change  is  complete. 
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4.5  Secure  Managetnent  process  Control 


4.5.1  The  TCB  shall  mediate  access  to  processes  and  objects.  An 
individual  address  space  shall  be  provided  for  each  process  (often  cal  leu 
a  "per  process  virtual  space")  ana  the  TCB  shall  mediate  access  to  these 
spaces.  The  requirement  for  individual  address  space  shall  not  preclude 
the  sharing  of  contents  of  such  address  space  under  TCB  control.  The  TCB 
shall  manage  in  a  trusted  way  scheduling  execution  time  among  the 
processes. 

4.5.2  An  inter-process  communication  (IPC)  feature  shall  be  provided  for 
authorized  cooperating  processes.  The  TCB  shall  enforce  "conf inemenv" 
upon  the  IPC  feature. 

4.5.3  Tne  TCB  shall  provide  a  Create-Process  feature  which: 

a.  Assigns  execution  space  for  a  specific  process. 

b.  Associates  subject  identity  with  the  created  process, 

c.  Assigns  subject  protection  attributes  to  the  createu  process. 

d.  Assigns  address  space  for  data  accessible  by  the  created  process 

e.  Guarantees  that  the  effects  of  the  creation  process  are  not 
visible  below  the  security  level  of  the  created  process.  Tnii  snoulu  not 
preclude  the  capability  in  4. 3. 1.4. 

4.5.4  The  TCB  shall  provide  a  Delete-Process  feature  wliicn: 

a.  Purges  execution  space  from  the  process, 

b.  Purges  the  subject  identity  associated  with  the  process  to  be 
deleted, 

c.  Purges  the  protection  attributes  assigned  to  the  process  to  be 
deleted,  and 

d.  Purges  the  address  space  for  the  data  that  was  accessible  by  the 
process  to  be  deleted. 

e.  Guarantees  that  the  effects  of  the  deletion  process  are  not 
visible  below  the  security  level  of  the  deleted  process. 

4.5.5  If  provided,  an  Await-Process  shall  be  uncer  the  control  of  tne 
TCB  and  shall  have  the  capability  to  suspend  and  reschedule  a  process. 

4.5.6  The  TCB  shall  provide  a  Process-Session  feature  that  establishes 
to  a  well  defined  state  (e.g.,  all  zero's),  security  attributes  ana 
precedence  to  be  associated  with  the  process,  or  session,  prior  to 
initiating  that  process  or  session. 

4.G  Trusted  Path.  Each  I-S/A  AMPE  TCB  shall  support  trusted 
comnumcations  paths  between  itself  and  subscribers  for  use  when  a 
positive  TCB-to-subscriber  contrection  is  required  (e.g.,  by  tne  Security 
Administrator  at  the  Security  Administration  Position).  Communications 
via  this  trusted  path  shall  be  activated  by  the  TCE  or  the  entity  at  ttie 
other  end  and  shall  be  logically  and  unmistakably  distinguished  froiii 
other  paths. 


4.7  Control  Information.  The  information  that  is  passed  to  a  process 
shall  be  contined  by  the  TCB  to  that  information  necessary  for  execution. 

4.8  TCB  Span-of-Control .  In  the  I-S/A  AMPE  the  TCB  shall  either 
directly  or  indirectly  control  all  processes.  The  TCB,  to  meet  other 
requirements,  must  be  relatively  siiiall  to  facilitate  verification  ano  be 
designed  for  minimum  impact  on  system  throughput;  thus  i,reat  care  must  be 
exercised  in  deterininini^  which  functions  are  part  of  tne  TCB.  Of  special 
concern  are  processes  which  allow  access  such  as  input  and  output.  All 
input  and  output  shall  be  under  the  control  of  the  TCB. 

4.9  Management  of  Storage  Objects.  The  term  "storage  object"  refers  to 
those  objects  that  support  read  and  write  access.  The  TCB  shall  provide 
the  capability  to  create  and  delete  storage  objects. 

4.9.1  The  Create-Object  feature  shall: 

a.  Uniquely  identify  each  storage  area  as  an  object, 

b.  Assign  the  security  label  to  each  storage  object,  and 

c.  Allocate  the  domain  and  extent  of  each  storage  object 

4.9.2  The  Delete-Object  feature  shall; 

a.  Disassociate  the  identity  of  the  storage  area  as  an  object, 

b.  Purge  the  security  label  and  ttie  content  of  the  storage  ou^ect 
by  changing  it  to  a  well  defined  state  (e.g.,  all  zeros), 

c.  Deallocate  the  doinain  and  extent  of  each  storage  object. 

4.10  Storage  Reuse. 

4.10.1  The  TCB  shall  provide  for  the  purging  of  each  area  of  storage 
before  it  is  introduced  for  reuse. 

4.10.2  Requirements  for  elimination  of  residual  information  shall  be  met 
as  specified  in  JCS  Pub.  22,  DoD  C-5200.28-M,  and  USSID  702. 

4.11  IAS  Network  Security. 

In  order  to  obtain  access  to  the  packet  switching  backbone,  an  Al 
certified  and  accredited  H^P  element  must  be  in  place  between  the  I-S/A 
AMPE  and  the  Defense  Data  Network  (DDN)  node.  The  H^p  element  will  be 
government  furnished  from  the  BLACKER  program.  The  I-S/A  AKPE  to  H^p 
element  interface  that  is  specified  will  also  serve  as  the  H^p  element 
to  DDN  interface.  All  applicable  mandatory  and  discretionary  security 
shall  be  enforced. 

4.12  Idontif icatio n.  Authentication  and  Indivi dual  Acountabi 1 ity . 

4.12.1  The  I-S/A  AMPE  shall  identify  and  authenticate  each  subscriber 
and  identify  each  operating  position  collocated  with  the  I-S/A  AMPE.  Tne 
identification  shall  include  the  unique  identity  of  the  subscriber  and 
its  authorized  security  attributes  as  well  as  the  terminal  ana  its 
accredited  security  level. 
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4.12.2  Authentication  data  shall  be  protected  so  that  it  cannot  be 
acquired  by  an  unauthorized  subscriber  or  individual. 

4.12.3  The  I-S/A  AKPE  shall  associate  the  subscriber's  identity  with  all 
auditable  actions  taken  by  that  subscriber  (e.g.,  retrieval  request). 

The  I-S/A  AMPE  shall  have  the  capability  to  identify  and  authenticate 
(e.g.,  passwords)  an  individual  and  mediate  the  activity  of  individuals 
at  the  I-S/A  AMPE  operating  positions.  In  these  circumstances,  the  I-S/A 
AMPE  shall  include  the  individual's  identification,  in  addition  to  the 
subscriber  identification,  with  all  actions  taken  by  that  individual. 

4.13  Security  Audit. 

4.13.1  All  subscribers  accessing  the  I-S/A  Al-IPE  are  required  to  provide 
positive  subscriber  identification  and  have  available  positive  individual 
identification  for  an  audit  trail.  Tnis  is  necessary  to  ensure  that  an 
unbroken  path  of  responsibility  can  be  subsequently  audited.  This  audit 
trail  begins  with  the  drafters,  includes  the  releaser,  the  subscriber's 
operator,  the  subscriber  terminal,  the  I-S/A  AMPE,  the  exit  ano  entry 
to/from  IAS  Network,  the  receiving  I-S/A  AMPE,  receivirii^  terminal,  an 
operator  ana  finally  the  recipient;  in  short,  wr iter-to-reader.  Each 
I-S,A  AMPE  shall  maintain  an  audit  trail  of  those  auditable  events  which 
occur  only  while  a  message  is  being  processed  by  that  I-S/A  AMPE.  On  a 
subscriber  basis,  each  subscriber  shall  be  classmarked  in  the  Attribute 
Table(s)  as  either  requiring  subscriber  identification  only  or  requiring 
both  subscriber  ana  individual  identifications.  For  I-S^A  AMPE  operating 
positions  both  positive  position  and  individual  identifications  shall  be 
required. 

4.13.2  The  I-S/A  AMPE  shall  create,  maintain,  and  protect  from 
modification  or  unauthorized  access  or  destruction  an  audit  trail  of 
access  to  the  objects  it  protects.  The  audit  data  shall  be  protected  by 
the  TCB  so  that  read  access  to  it  is  limited  to  those  who  are  authorized 
access  to  audit  data.  The  I-S/A  AMPE  shall  be  able  to  record  the 
following  types  of  events:  use  of  identification  and  authentication 
mechanisms,  introduction  of  objects  into  the  users  address  space  (e.g., 
file  open,  program  initiation),  and  the  deletion  of  objects.  For  each 
recorded  event,  the  audit  record  shall  identify:  date  and  time  of  tne 
event,  and  the  success  or  failure  of  the  event.  For 
identification/authentication  events  the  origin  of  the  request  (e.g., 
terminal  ID,  subscriber  ID,  individual  ID  )  shall  be  included  in  the 
audit  record.  In  addition,  the  I-S/A  AMPE  shall  be  able  to  record 
actions  taken  by  the  I-S/A  AMPE  operators,  Systein  Administrators,  and/or 
Security  Administrators.  The  Security  Administrator  shall  be  able  to 
selectively  audit  the  actions  of  any  one  or  more  subscribers  baseo  on 
individual  identity. 

4.13.3  Time  sensitive  results  of  security  monitoring  features  shall  be 
provided  to  the  Security  Anmin istrat.ion  Position  with  precedence  handling 
equivalent  to  FLASH. 

4.13.4  Once  recorded  the  TCB  shall  ensure  the  integrity  of  Audit 

Trail (s)  and  permit  read  only  access  from  an  operating  position  connected 
via  a  Trusted  Path. 
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4.13.5  TCB  controls  shall  be  provided  for  momtoriny  the  occurrence  of 
auditable  events  and;  notifying  the  Security  Administration  Position,  and 
taking  the  least  disruptive  course  of  action  when  programmed  thresholds 
are  exceeded.  If  the  event  persists  the  TCB  shall  have  the  capability  to 
protect  the  system  by  taking  stronger  action  necessary  to  preserve  system 
security.  I-S/A  AMPE  auditable  events  shall  include  as  a  minimuni: 

4.13.5.1  Unauthorized  Access  Attempts.  Correctly  formatted  access 
requests  which  contain  errors  shall  be  recorded  for  audit  upon 
occurrence.  The  threshold  for  operator  notification  shall  be  adjustable 
in  the  range  of  1  to  10  per  hour  by  the  security  administrator  for  eacn 
subscriber,  operator,  and  subsystem.  When  the  threshold  of  10  per  hour 
is  reached,  the  TCB  shall  cause  the  access  path  to  be  disabled  with 
notification  to  the  operator  and  an  audit  trail  record  createa. 

4.13.5.2  Illegal  Access  Attempts.  Unrecognizable  data  during  initiation 
of  access  shall  be  recorded  in  the  audit  trail,  including  content,  upon 
occurrence.  The  threshold  for  operator  notification  shall  be  adjustable 
in  the  range  of  1  to  5  per  hour  by  the  system  operator  for  each 
subscriber,  operator,  and  subsystem.  When  the  threshold  of  5  per  hour  is 
reached,  the  TCB  shall  cause  the  access  path  to  be  disabled  witn 
notification  to  the  operator  and  an  audit  trail  record  created. 

4.13.5.3  System  and  Subsystem  Faults.  System  and  subsystem  faults  which 
occur  shall  be  recorded  in  the  audit  trail  if  possible.  The  operator 
shall  be  notified  of  all  system  and  subsystem  faults.  The  TCB  shall 
execute  security  confidence  tests  prior  to  restart  after  a  system  or 
subsystem  fault. 

4.13.5.4  System  and  Subsystem  Restarts.  All  system  and  subsystein 
restarts  shall  be  recorded  in  the  audit  trail  with  the  identification  of 
the  initiator  of  the  restart.  The  operator  shall  be  notified  of  all 
system  and  subsystem  restarts. 

4.13.5.5  Security  Administration  Actions.  All  actions  of  the  Security 
Administrator  shall  be  recorded  with  the  identification  of  the  indiviuual 
initiating  the  action.  All  action  of  the  Security  Administrator  shall  be 
presented  for  review  on  the  initiating  device  prior  to  implementation  of 
the  results.  Security  Administrator  actions  shall  be  treated  as  security 
label  changes. 

4.13.5.6  Operator  Actions.  All  actions  of  the  operators  shall  be 
recorded  in  the  audit  trail  with  the  identification  of  the  operator  ana  a 
means  of  auditing  the  content  of  the  action. 

4.13.5.7  Inactivity  timeouts.  Inactivity  timeouts  shall  be  recordea  in 
the  audit  trail  with  the  identification  of  the  subscriber.  Tne  timeout 
threshold  shall  be  adjustable  in  the  range  of  1  to  99  minutes  by  the 
system  operator  for  each  subscriber.  Subscribers  with  individual 
identification  requirements  shall  be  required  to  reestablish  access 
subsequent  to  reaching  the  threshold  and  before  access  is  again 
permitted.  The  operator  shall  be  notified  of  Subscriber  Access 
Terminations  and  reactivations  due  to  timeouts. 
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4.13.5.8  Modifications  to  the  accesses  accorded  to  individual  users 
shall  be  recorded  in  the  audit  trail  with  the  identification  of  the 
initiator  and  the  effected  user.  The  TCB  shall  ensure  tiiat  the 
modification  does  not  cause  the  permissiotis  established  by  the  Security 
Administrator  to  be  exceeded.  Attempts  to  exceed  security  access 
attributes  shall  be  treated  as  unauthorized  access  attempts. 

4.13.5.9  Security  relcted  hardware  and  software  failures.  All  security 
related  hardware  and  software  failures  shall  be  recorded  in  the  audit 
trail.  Failure  shall  cause  the  TCB  to  execute  security  confidence  tests 
which  shall  permit  the  security  of  the  system  to  be  reestablished. 
Processing  shall  be  suspended  until  the  system  security  is 
reestablished.  Attempted  execution  of  data  received  from  a  communication 
line  is  a  security  related  failure. 

4.13.5.10  Label  changes  shall  be  permitted  only  under  the  control  of  the 
TCB  and  only  when  initiated  by  the  Security  Administrator.  Label  Change 
Actions  shall  be  recordeo  in  the  audit  trail  with  the  before  and  after 
image  of  the  label. 

4.13.5.11  Diarncstical ly  detected  errors  shall  be  recorded  in  the  audit 
trail  and  the  operator  notified. 

4.13.5.12  The  occurrence  of  a  specified  number  of  serial  CAKTRAKs  from  a 
specified  terminal  without  an  intervening  valid  message  shall  be  recorded 
in  the  audit  trail  and  the  I-S/A  AMPE  system  operator  shall  be  notified. 

4.13.3  TCP  features  shall  be  invoked  to  recoro  History  and  Journal 
File(s)  information.  In  particular,  tne  following  shall  always  be 
recorded  per  DoD  C-503C.58X: 

4.13.6.1  Unauthorized  internal  and  external  access  attempts 

4.13.6.2  Message  identifiers  :  security,  Channel  Designation  and  Channel 
Sequence  Number  (CD  and  CSN),  Transmission  Control  Code  (TCC), 

Originating  Station  Routing  Indicator  (CSRI),  Destinations,  Date  Time 
Group  (DTG),  the  classification  level  identified  in  Format  Line  12,  and 
the  Unique  Message  Identifier 

4.13.6.3  Retrieval  data  :  message  requested,  when  requested,  disposition 
(allowed  or  denied),  and  destination 

4.13.6.4  Security  faults  :  identification  of  rejected  message,  reason, 
disposition,  when,  and  action  taken 

4.13.6.5  Security  attribute  changes  :  changes  to  security  labels, 
changes  to  routing  tables  including  alternate  routing  tables,  authority 
for  change,  discretionary  access  change 

4.13.7  TCB  Features  shall  be  provided  to  support  the  following 
activities: 

4.13.7.1  Accouritabi  1  ity  of  classified  data; 

4.13.7.2  Investigations  of  suspected  security  violations. 
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4.13.8  Features  shall  be  provided  to  audit  system  security  related 
activities  to  provide  a  history  of  systeiii  security  relevant  information 
(Reference  DoD  5200. 28-M,  JCS  Pub  22,  DIAM  50-4  and  DoD  C-5030.58H).  For 
each  activity  the  History  File(s)  shall  include  the  user,  resource,  type 
of  access  attempted  or  obtained,  day  and  time. 

4.13.9  Features  shall  be  provided  for  the  capability  to  audit  the  use  of 
the  covert  channels  identified  duriny  the  formal  verification  of  the  FTLS 
that  have  bandwidths  that  may  exceed  a  rate  of  one  bit  in  ten  seconds. 


4.14  Security  Administration  Support 

4.14.1  The  I-S/A  AMPE  shall  provide  the  following  trusted  features  to 
support  the  Security  Administration  Position: 

4.14.1.1  Audit  system  security-related  activities 


4.14.1.2  Determine  system  configuration 

4.14.1.3  Establish  and  change  classification  markings  on  objects 
other  than  messages 

4.14.1.4  Establish  and  control  access  authorization 


4.14.1.5  Enable  and  disable  subscriber  access  authorizations  and 
activities 


4.14.1.6  Enable  and  disable  subscriber  connections 


4.14.1.7  Selectively  enable  or  disable  diagnostics 

4.14.1.8  Select  security  hardware  and  software  monitoring  intervals 

4.14.1.9  Run  confidence  tests 

4.14.2  The  Security  Administration  function  shall  only  be  invoked  from 
correctly  classmarked  I-S/A  AMPE  operating  positions  and  throuaii  the  use 
of  authentication  procedures.  Individual  and  terminal  identification  ana 
authentication  shall  be  used  to  ensure  continuity  of  operations. 

4.15  System  Generation  and  Loading. 

At  system  start-up  and  for  all  subsequent  reload  and  restart 
situations,  the  TCB  for  the  I-S/A  AMPE  should  be  loaded  first.  After  the 
TCE  has  been  successfully  loaded,  the  remainder  of  the  I-S/A  AMPE  program 
shall  be  loaded  under  TCB  control. 

4.15.1  A  validated  automatic  sequence  of  operations  for  loading  and 
initializing  the  CIs,  CPCis,  and  CPCs  of  the  I-S/A  AI'IPE  including 
establishment  of  the  initial  secure  state  for  the  TCB  shall  be  provided. 
This  sequence  shall  also  validate  the  correct  functioning  of  those 
hardware  CIs  of  the  system  which  are  included  within  the  TCB. 


4.15.2  The  loading  operations  shall  not  depend  upon  any  untrusted  system 
CIs,  CPCIs,  or  CPCs  for  correct  functioning.  Any  errors  detectea  in  the 
loading  or  initialization  function  shall  result  in  operator  error 
messages  and  cause  the  system  to  halt. 


4.15.3  All  subsequent  loading  operations  shall  be  performed  under  the 
control  of  the  TCB.  Reloading  operations  shall  ensure  the  integrity  of 
the  TCB  and  shall  re-establish  a  secure  state  prior  to  return  to  service. 

4.15.4  Diagnostics  shall  be  performed  to  verify  the  integrity  of  the  TCb 
during  system  startup  and  prior  to  systeii,  operation. 

4.16  Trusted  Restoral 

4.15.1  Features  shall  be  provided  to  ensure  tiie  trusted  accompl i^hiiient 
of  functions  and  to  assure  restoral  of  the  I-S/A  AMPE  to  a  demonstrataoly 
secure  state. 

4.16.2  Check  point  or  other  environmental  "snap-shots"  features  shall 
operate  under  the  control  of  the  TCB. 

4.16.3  The  restart  features  shall  rebuild  from  the  last  coiupletely 
consistent  record  for  which  a  secure  state  was  recorded. 

4.17  Security  Tests 

Features  shall  be  provided  to  periodically  conduct  comprehensive 
security  tests  of  the  entire  system  without  degrading  operational 
performance  parameters  identified  in  para  3.5  of  the  FRD.  Tnese  tests 
shall  be  executable  in  real-time  with  the  on-line  system  throuahout  tne 
life  of  the  I-S/A  AMPC  ana  shall  provide  the  necessary  information  to 
support  security  related  investigations. 

4.13  Safe  Storage  of  Information 

Upon  receipt,  incoming  messages  shall  be  entered  into  the  I-S/A  AMPE 
storage  by  the  TCB.  Following  this  action,  an  acknowledgement  will  be 
sent. 

4.19.  Security  Diagnostics.  The  I-S''A  AMPE  shall  include  features  for 
diagnosTng  the  operation  oT  security-related  CIs,  CPCIs,  CPCs. 

4.19.1  Diagnostics  shall  not  interfere  with  the  correct  functioning  of 
the  TCB  or  other  I-S/A  AMPE  features. 

4.19.2  The  security  policy  enforced  by  the  TCB  shall  not  be  relaxed 
while  on-line  diagnostic  functions  are  executing  or  during  any  degraded 
conditions  detected  by  the  diagnostic  functions. 

4.20  Communications  Security.  All  I-S/A  AMPE  transmission  media  shall 
be  secured.  A  Protected  k'ireline  Distribution  System  (PaDS),  secured  in 
accordance  with  f.’ACSEM  5203;  a  Host-to-Host  Protection;  and/or  link 
encryption  Government  approved  cryptographic  equipment  will  be  employed. 

4.21  Compromising  Emanations  Control  (TEMPEST) .  All  equipment  shall  be 
designed  to  reduce  Tlectroma'gn'el'ic  compromising  emanations  below  tlie 
applicable  radiation  and  conduction  limits  of  NACSIM  5100A  and  RACSEM 
5112  for  hardened  equipment  and  NACSIM  5100A  for  non-hardened  equipment. 
.Ml  TEMPEST  designs  shall  follow  NACSEK  5201.  Equipment  installation 
shall  conform  to  the  applicable  requirements  of  KIl-HIBK  232  or  R'ACSEM 
5203. 


DEVELOPMENT 


5 . 1  Formal  Security  Model. 

5.1.1  The  contractor  shall  develop  a  mathematical  "model" 
implementing  the  DoD  security  policy  which  describes  the  intended 
securi  ■'  behavior  of  the  TCB.  The  contractor  shall  provide  an  EribUsh 
language  description  which  explains  the  meaning  of  the  model.  The 
model  will  be  subject  to  review  by  the  Government.  (The  Government 
will  provide  documentation  describing  mathematical  models  (e.g..  Bell 
and  Lapadula)  developed  for  existing  DoD  programs  upon  request.) 

5.1.2  The  model  shall  specify  and  be  consistent  with  the  security 
policy  cited  in  Section  3  of  this  document. 

5.1.3  The  model  siiall  be  in  a  form  suitable  for  use  in  the  formal 
verification  of  the  TCB  design  specifications. 

5.1.4  The  model  shall  explicitly  identify  abstract  classes  of 
subjects  anci  objects  of  the  I-S/A  AMPE. 

5.1.5  The  model  shall  define  the  rules  governing  subject  and  object 
interactions . 

5.1.6  The  model  shall  be  shown  to  be  consistent  with  and  sufficient 
to  allow  satisfaction  of  the  functional  capabilities  specified  in  the 
Functional  System  Specification.  The  model  shall  be  sufficient  as 
well  as  consistent  with  respect  to  the  management  of  the  security. 

5.1.7  The  confinement  properties  of  the  overall  system  shall  be 
described  by  the  model. 

5 . 2  Verified  Des ign  -  Top  Level  Specification . 

5.2.1  A  formal  development  methodology  shall  be  used  in  the 
specification,  design,  analysis,  and  verification  of  security  related 
CIS,  CPCIs,  and  CPCs. 

5.2.2  Formal  Top  Level  Specifications  shall  be  prepared  for  the  TCB 
and  included  as  part  of  the  MIL-STD  490  B-5  specifications.  The 
Formal  Top  Level  Specifications  shall  be  verified,  using  verification 
techniques,  to  conform  to  the  security  behavior  of  the  mathematical 
security  model.  Verification  evidence  snail  be  consistent  with  that 
provided  within  the  state-of-the-art  of  the  selected,  accepted,  formal 
specification  and  verification  techniques.  These  techniques  shall  be 
approved  by  the  government  before  verification  is  initiated. 

5.2.3  Formal  Top  Level  Specification  shall  include  definitions  and 
functions  characteristics  of  hardware  and/or  firmware  mechanisms  that 
are  wi rhin  the  TCB. 
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5.2.4  The  correspondence  shall  be  shown  between  the  elements  of  the 
Formal  Top  Level  Specification  and  the  elements  of  tne  system  design 
as  implemented.  System  software  design  shall  express  the  protection 
required  of  the  DoD  security  policy.  The  correspondence  shall  be 
shown  between  detailed  design  specifications  of  the  ^jrotection 
elements  and  the  elements  of  the  Formal  Top  Level  Specification. 

5.2.5  Access  control  verification  and  information  flow  analyses  shall 
be  applied  iteratively  during  the  design  and  implementation  processes 
(e.g.,  successive  refinements  of  Cl,  CPCI,  and  CPC  design).  Errors 
detected  by  the  formal  analyses  shall  be  corrected  and  formal  analysis 
reiterated  until  complete. 

5 . 3  ^es ign  Analysis. 

5.3.1  The  contractor  shall  demonstrate  how  the  TCB  implements  the 
Formal  Top  Level  Specification. 

5.3.2  The  contractor  shall  describe  how  the  TCB  implementation 
satisfies  the  security  protection  features  for  an  implementation  of  a 
reference  monitor  (e.g.,  always  invoked,  tamperproof,  and  a  correct  ^ 
implementation  of  policy  model)  and  how  the  TCB  shall  be  structured  to 
facilitate  testing  and  to  enforce  mandatory  and  discretionary  DoD 
security  policy. 

5.3.3  The  contractor  shall  provide  documentation  that  presents  the 
results  for  the  confinement  channel  analyses  ano  the  tradeoffs 
involved  in  restricting  the  covert  use  of  such  cnannels. 

5.3.4  The  contractor  shall  use  formal  techniques  that  are 
mathematically  based,  to  identify  timing  channels,  witniri  the  TCB,  to 
the  Government.  An  estimate  of  the  bandwidth  and  countermeasure 
recommendations  shall  also  be  provided  by  the  contractor. 

5.3.5  The  contractor  shall  provide  analyses  of  the  primitive 
protection  mechanisms  used  to  iiiiplement  tlie  formal  model,  mechanisins, 
and  features  of  the  TCB. 

5.3.6  The  contractor  shall  provide  comprehensive  formal  reviews  as 
specified  by  MIL-STD-1521C. 

5.3.7  The  contractor  shall  provide  documentation  ana  analysis  on  the 
protection  elements  of  the  system  which  address  detection  or 
prevention  of  actions  which  could  result  in  disruption  or  denial  of 
service. 

5 . 4  Development  Environment . 

5.4.1  The  contractor  shall  provide  a  developmental  environment  which 
prohibits  the  exposure  of  all  products,  to  include  development  tools, 
(whether  deliverable  or  not)  to  unauthorized  access.  Access  to  all 
such  products  shall  be  controlled  commensurate  with  the  security 
levels  of  the  products  or  other  measures  specified  by  tlie  Government 
(e.g.,  DoC  5220.22m,  "Industrial  Security  Manual  for  Safeguardirij 
Classified  Information"). 
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5.4.2  All  system  documentation  (e.9.,  developmental  software  tools) 
shall  be  protected  in  accordance  with  current  regulations  regarding  the 
protection  of  inforiiiation  as  specified  by  the  Government. 

5.5  Trusted  Software  Development  and  Documentation. 

5.5.1  The  contractor  shall  develop  a  separate  section  in  the  l-lIL-STb  490 
Type  A  Specification  which  shall  consolidate,  in  a  comprehensive  form, 
all  the  pertinent  security  related  issues  and  solutions  defined  in  the 
other  parts  of  the  specification  with  appropriate  references  to  those 
other  parts.  The  security  section  shall  describe  the  security  related 
hardware  and  software  in  terms  of  CIS,  CPCIs,  and  CPCs  respectively. 

5.5.2  State-of-the-art  software  engineering  techniques  shall  be  applied 
in  all  phases  of  system  development.  Software  production  shall  be 
consistent  with  modern  engineering  practice  (e.g.,  top-aown  structured 
programming,  information  hiding,  loop-free  module  hierarchy,  stepwise 
refinements,  stubs). 

5.5.3  Protective  measures  shall  be  designed  to  detect  attempts  to  taiiyer 
with  evolving  software  ana  hardware. 

5.5.4  Software  will  be  developed  in  a  SECRET  environment.  Tne  software 
itself  will  be  assigned  any  classification  necessary  based  on  information 
contained.  Strict  configuration  control  shall  be  employed  to  protect 
against  unauthorized  hardware  and  software  changes. 

5.5.5  Programming  languages  used  in  the  iiivlementation  of  the  TCB 
software  shall  be  selected  with  consideration  to  their  suitability  for 
the  valication  and  verification  of  the  design  specifications  and  tne  High 
Order  Language  code.  These  programming  languages  proposed  shall  be 
submitted  to  the  Government  for  approval. 

5.5.6  Programming  shall  be  performed  using  design  methods  that  support 
rigorous  implementation  of  the  design  (i.e.,  the  correspondence  between 
the  design  and  its  implementation  can  be  verified).  The  contractor  shall 
provide  validation  of  all  security  related  software  and  thus  demonstrate 
the  correspondence  between  specifications  and  CPCs). 

5.5.7  All  software  considered  for  use  within  the  I-S/A  AMPE  shall  be 
evaluated  for  suitability  and  operation  in  conjunction  with  the  system 
security  policy.  The  contractor  shall  provide  convincing  evidence 
supporting  the  ability  of  the  choosen  CIs,  CPCIs  and  CPCs  to  interoperate 
with  the  I-S/A  AMPE  TCB. 

5.5.8  The  contractor  shall  proviae  the  following  documentation: 

a.  Results  of  functional  testing  of  the  security  features  and  the 
efectiveness  of  the  confinement  channel  minimization. 

b.  The  mappings  for  correspondence  between  the  Formal  Top  Level 
Specification  and  all  security  protection  related  CIs,  CPCIs,  and  CPCs. 


5 . 6  System  Security  Plan. 

5.6.1  The  contractor  shall  submit  a  system  security  plan  to  tlie 
Government  for  approval  which  describes  the  strategy  for  the  design, 
development,  ana  implementation  of  the  I-S/A  AMPE.  The  System  Security 
Plan  shall  include  a  description  of  the  organizational  structure, 
staffing,  and  functional  activities  which  will  be  used  by  the  contractor 
to  support  the  security  engineering  effort. 

5.6.2  The  System  Security  Plan  shall  describe  verification  techniques  to 
be  followed  during  system  design  and  development.  The  System  Security 
Plan  shall  describe,  in  detail,  the  elements  and  relationships  for  the 
following  tasks: 

a.  Development  of  mathematical  security  model. 

b.  Development  of  Formal  Top  Level  Specifications  for  the  design  of 
the  system  security  mechanisms. 

c.  Development  of  formal  validation  methods  to  verify  that  tiie 
Formal  Top  Level  Specifications  conform  to  the  rules  of  the  mathematical 
security  model,  that  is,  documentation  shall  oe  provided  that  describes 
the  analysis  tecliniques  that  produce  theorems  to  be  proven  about  the 
formal  specifications. 

d.  Verification  of  the  CIs,  CPCIs,  and  CPCs  developed  to  implement 
the  Formal  Top  Level  Specification. 

e.  Analysis  efforts  (e.g.,  trade-off  analysis). 

f.  Security  testing. 

5.6.3  The  contractor  System  Security  Plan  shall  be  updated,  as 
necessary,  during  the  course  of  the  I-S/A  AMPE  development  and  shall  be 
subject  to  Government  approval  prior  to  intplementing  proposed  changes. 

5.7  Trusted  Computing  Base.  The  CIs,  CPCIs,  and  CPCs  which  perform 
securTty  reTated  functions  shall  be  shown  to  be:  segregated  from  tiie 
rest  of  the  system,  isolated  to  prevent  tampering,  and  provide  protection 
from  unauthorized  access. 

5.7.1  The  contractor  shall  provide  verification  evidence  (i.e.,  formal 
proof,  test  plans  and  test  results)  that  all  CIs,  CPCIs,  and  CPCs  whicn 
perform  ‘•ecurity  related  functions  are  within  the  TCB.  Tne  Government 
will  approve  the  selection  of  the  TCB  elements.  The  correct  operation 
and  integrity  of  the  CIs,  CPCIs,  and  CPCs  within  the  TCB  shall  be  shown 
to  be  independent  of  the  actions  of  CIs,  CPCIs,  and  CPCs  outside  the  TCB. 

5.7.2  The  security  of  the  TCB  shall  be  demonstrated  by  tne  contractor 
and  certified  by  the  Government  as  providing  the  requisite  nFotection 
from  unauthorized  disclosure  (compromise),  denial  of  service,  and 
unauthorized  alteration  of  data. 
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5.7.3  The  contractor  shall  demonstrate  the  ability  of  the  computer 
system  to  provide  reliable  and  efficient  service. 

5.7.4  The  contractor  shall  demonstrate  how  his  design  minimizes  the 
extent  of  the  TCB  including  all  CIs,  CPCIs,  and  CPCs.  Hardware  that 
provides  mechanisms  for  isolating  security  features  and  controlling  the 
flow  of  information  between  isolated  contexts  is  encouraged  (e.g., 
segmentation  and  protection  domains). 

5.7.5  The  contractor  shall  provide  capabilities  to  detect  failures  in 
TCB  related  CIS,  CPCIs,  and  CPCs. 


5.8  Trusted  Process  Identification.  The  contractor  shall  specify  which 
CIs,  CPCIs,  and  CPCs  compose  the  TCB  and  the  rationale  for  selection  of 
each  Cl,  CPCI,  and  CPC.  The  government  will  certify  that  the  Specified 
list  is  necessary  and  complete  for  the  TCB. 

5.9  Security  Audit. 


5  9.1  The  contractor  shall  develop  a  detailed  nsting  uf  inforiuatioii  to 
be  audited,  including  rationale  for  the  selection  of  each  audited  item. 
The  list  shall  be  approved  by  tlie  Government. 


1  1  St  1  Hij 


5.9.2  The  contractor  shall  provide  an  assessment  of  the  capabilities  to 
detect  failures  in  CIs,  CPCIs,  and  CPCs,  which  are  part  of  the  TCB. 
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IMPLEMENTATION' 


6.1  Implementation  and  Trusted  Distribution.  Implementation  shall 
employ  a  language  for  which  there  is  a  well  understood,  reliable  lanijuai^e 
processor  (e.g.,  coinplier).  There  are  some  languages  {e.g.»  GYPSY, 

EUCLID)  that  have  been  designed  with  the  intention  that  programs  written 
in  them  be  formally  verified.  Other  languages  (e.g.,  PASCAL)  have 
proposed  designs  to  implement  "verifiable  subsets."  Experience  to  date 
indicates  that  a  reliable  language  processor  and  the  disciplined  use  of  a 
conventional  language  are  preferable  to  a  relatively  untested  language 
processor  and  a  "to  be  verifiable"  language.  The  contractor  shall  assure 
the  following: 

6.1.1  The  FTLS  of  the  TCB  shall  be  written  using  a  Verifiable  Formal 
Logic  (YFL)  (e.g..  Formal  Specification  Languages,  Formal  Graphics, 
Program  Design  Language  (PDL))  that  facilitates  the  automated 
verification  of  completeness  and  sufficiency  of  the  implementation  of  the 
FTLS.  This  verification  will  encourage  that  the  systeiii  be  structured  and 
use  well  defined  primitives  and  a  loop-free  module  hierarchy.  Module 
hierarchy  is  referenced  in  an  MIT  doctorial  dissertation  titled  "Using 
Type  Extention  to  Organize  Virtual  Memory  Mechanisms",  MIT/LCS/TR-167, 

MIT,  September  1976  by  Janson,  P.A. 

6.1.2  The  TCB  shall  be  written  using  a  High  Order  programming  Language 
(HOL)  and  using  structured  and  well  defined  primitives  (e.g., 

"DO. . .WHILE",  "IF. . .THEN. . .ELSE"),  that  permit  a  loop-free  moaule 
hierarchy. 

6.1.3  The  source  language  statements  of  the  TCB  shall  be  well  documented. 

6.1.4  The  language  selected  for  software  implementation  shall  be 
justified  for  suitability  in  terms  of  cost,  schedule,  quality  of  compiler 
and  tools,  and  technical  performance. 

6.1.5  Use  of  control  structures  shall  be  justified  to  be  a  minimum 
implementation  necessary  to  realize  TCB  features. 

6.1.6  The  Formal  Top  Level  Specifications  shall  be  baselined  as  trie 
"certified  design"  for  resolution  of  design  issues. 

6.1.7  The  contractor  shall  develop  a  well  defined  and  documented  set  of 
procedures  for  system  generation  and  loading.  These  procedures  shall 
ensure  the  integrity  of  the  TCB  during  system  generation  and  loading. 

6.1.8  The  contractor  shall  develop  a  procedure  for  ensuring  that  the 
system  software,  microcode,  and  hardware  updates  distributed  are  exactly 
as  specified  by  the  master  copies.  Such  procedures  shall  include  site 
security  acceptance  testing.  The  contractor  shall  provide  audit 
procedures  for  an  I-S/A  AMPE  to  the  Government  for  approval. 

6.1.9  The  procedure  for  implementing  the  requirements  of  Paragraph  6 
shall  be  submitted  to  the  Governmnet  for  approval. 
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TEST 


7.1  Security  Testing.  Thorough  testing  continues  to  be  a  necessary 
requirement  in  the  design  and  implementation  of  multilevel  secure 
systems.  When  test  plans  are  constructed,  specific  attention  shall  be 
given  to  testing  the  security  provisions  of  the  system. 

7.1.1  The  contractor  shall  arrange  for  penetration  tests  by  the 
Government  and  estimate  the  bandwidth  of  confinement  channels  that  cannot 
be  eliminated. 

7.1.2  The  Government  shall  provide  to  the  contractor  a  list  of 
paragraphs  of  the  Functional  System  Specification  which  are  testable,  and 
shall  cross  reference  these  paragraphs  with  the  test(s)  which  are  used  to 
verify  that  compliance.  The  cross  reference  shall  establish 
correspondence  from  the  Functional  System  Specification  through  the  CIs, 
CPCIs,  and  CPCs  verified  by  the  test{s).  Additionally,  each  test 
procedure  shall  identify  which  paragraph(s)  of  tne  Functional  Systeiii 
Specification  are  being  verified. 

7.1.3  The  contractor  shall  input  test  combinations  against  the  system 
security  mechanism.  The  TCB  shall  be  tested  using  valid  anu  invaliu 
input  combinations  under  normal  and  stress  scenarios  to  exercise  each  Cl, 
CPCI,  and  CPC.  Stress  testing  scenarios  shall  be  developed  by  the 
contractor  and  approved  by  the  Government.  Each  security  feature 
(operational  as  well  as  configuration  related)  shall  be  teiteo. 

7.1.4  The  contractor  shall  select  a  test  approach  designed  to  exercise 
each  CPC  (referencing  at  least  one  relevant  security  test  which  executes 
that  CPC).  Strict  configuration  control  shall  be  employed  for  any 
changes  in  the  test  procedure,  data,  or  the  system  to  be  tested.  The 
testing  approach  shall  ensure  that  changes  to  CIs,  CPCIs,  or  CPCs  are 
adequately  tested  to  detect  any  affects  of  the  changes. 

7.1.5  The  maximal  use  of  the  formal  specifications  shall  be  used  in  the 
development  of  test  sets. 

7.1.6  Prior  to  Government  Acceptance  Testing,  the  contractor  shall 
perform  the  system  security  test(s)  identified  in  para^^raph  7.1  above. 
These  tests  shall  be  performed  to  exercise  the  TCB  in  an  environment  that 
simulates  actual  operation.  Test  result  documentation  shall  be  provided 
to  the  Government  that  demonstrates  that  all  TCB  requirements  have  been 
met. 

7.1.7  When  test  results  indicate  that  the  TCB  does  not  meet  the 
Functional  System  Specification  requirements,  the  contractor  snail  be 
required  to  take  the  corrective  action.  Retesting  shall  be  required. 

7.1.8  Government  Security  Acceptance  Test.  The  Government  acceptance 
test  will  be  conducted  prior  to  a  Production  Buy  Decision.  Tne 
contractor  shall  provide  support  for  this  testing,  fhe  Government  will 
conduct  the  testing  and  prepare  the  test  report.  Latent  defects 
discovered  during  Government  acceptance  testing  shall  be  corrected  by  the 
contractor  within  the  scope  of  the  contract. 
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7.1.9  The  contractor  shall  provide  a  set  of  security  confidence  tests 
which  exercise  all  security  features  and  mechanisms  in  both  real-time  and 
on-line  modes  of  operation.  These  tests  must  be  available  throu9hout  the 
system  life  cycle,  shall  be  executed  periodically,  and  be  capable  of 
being  executed  on  any  I-S/A  AMPE  system  configuration.  These  tests  will 
include  specific  attributes  which  address  detection  or  prevention  of 
actions  which  could  result  in  disruption  or  denial  of  service. 


7.2  System  Performance.  The  contractor  shall  conduct  performance 
evaluations,  analyze  performance  results,  and  document  performance  levels 
achieved.  The  contractor  shall  demonstrate  that  the  required  performance 
level  has  been  achieved. 


'■pT, 
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VULNERABILITY  ANALYSIS 


C. 1  Vulnerability  Analysis. 

8.1.1  An  independent  contractor  should  perforin  a  comprehensive  system 
Clandestine  Vulnerability  Analysis  (CVA)  for  the  I-S/A  AMPE.  The  CVA 
shall  consist  of  the  allocation  of  critical  functions,  and  analyses  of 
countermeasures  for  the  I-S/A  AMPE  related  to:  hardware  and  software 
modifications,  the  effects  of  each  external  interface;  security-related 
special  functions  (e.g.,  TCB);  TEMPEST;  and  security  design  and 
development  approach  for  each  Cl,  CPCI,  or  CPC.  The  Government  shall 
provide  the  contractor  with  the  necessary  threat  information  to  perform 
his  CVA. 


8.1.2  An  i 
Review  and 
document  sh 
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fully  docuiii 
Each  update 
chdjjters )  G 
report  will 
report  shal 


nitial  CVA  report  shall  be  produced  for  the  System  Desiyii 
shall  be  updated  throughout  development  activities.  This 
all  be  classified  TOP  SECRET  until  Government  review  and  a 
ification  applied.  The  initial  CVA  report  and  updates  shall 
ent  the  contractor's  continuing  refinements  and  analyses. 

shall  form  separate,  clearly  delineated  portions  (e.g-., 
f  "the  tctsl  rspert  "finS!!  clsssi'f ic2t.ion  Isvsl  of  tris 

be  determined  by  the  Government.  The  chapters  of  the  CVA 
1  be  reviewed  bj  the  Government  as  they  are  proauced. 


0.1.3  Each  vulnerability,  threat,  and  related  countermeasure  will  be 
categorized  into  one  or  more  of  tne  following  areas:  unauthorized 
disclosure  (compromise),  denial  of  service,  or  unauthorized  alteration. 
The  contractor  shall  perforiii  an  analysis  to  deterinine  and  assess  the 
effectiveness  of  the  countermeasures  designed,  implemented,  and  employed 
by  the  I-S/A  AMPE.  The  Government  will  rank  the  vulnerabilities 
identified  the  CVA  according  to  ease  of  exploitation  and  the  potential 
benefits  to  the  exploiter.  All  I-S/A  AMPE  test  plans,  security 
alternatives,  and  procedures  shall  incorporate  CVA  results. 


0.1.4  As  part  of  the  CVA  report,  documentation  of  residual 
vulnerabilities  in  the  system  shall  be  prepared  and  countermeasures 
(e.g.,  procedures)  recommended  by  the  contractor. 

C.1.5  The  contractor  shall  provide  information  necessary  for  the 
Governiiient  to  conduct  an  independent  CVA. 
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CERTIFICATION  AND  ACCREDITATION  SUPPORT 


9.1  Certification  Support.  A  security  analysis  (e.g.,  security  testing 
and  penetration  testTny]  of  the  overall  I-S/A  AMPE  system  is  an  essential 
part  of  the  certification  process. 

9.1.1  The  contractor  shall  provide  support  for  Government  efforts 
related  to  the  security  certification  of  the  I-S/A  AMPE.  The  Government 
will  coordinate  security  evaluation  activities. 


9.1.2  The  Government  will  conduct  a  penetration  test  of  the  I-S/A  AMPE. 
Tlie  contractor  shall  support  this  effort  by  providing  full  access  to 
technical  expertise  (e.g.,  I-S/A  AMPE  designers  and  developers)  in  order 
to  gather  information  for  penetration  test  scenarios.  Tne  contractor 
shall  provide  support  for  operating  the  system  during  penetration  testing. 


9.1.3  The  Government  will  perform  analyses  of  the  I-S/A  AMPE  design  ana 
implementation  as  part  of  the  security  certification  effort.  The 
contractor  shall  provide  for  use  by  the  Government,  autoiiiated  design, 
implementation,  and  analysis  aids  used  during  the  development  of  the 
I-S/A  AMPE,  which  may  assist  the  Government  in  its  analysis  efforts.  The 
couLractor  shall  provide  reference  material  describnig  me  use  of  any 
aids  made  available. 


9.1.4  The  contractor  shall  make  available  to  the  Government,  on  magnetic 
ri.edia;  source  language  statements,  machine  object  code,  and  the  software 
support  environment  used  to  produce  anc  maintain  theiii. 

9.1.5  The  contractor  shall  develop  a  generic  certification  test  plan  to 
facilitate  the  certification  of  an  I-S/A  AKPE.  Tnis  test  plan  shall  be 
iiiodular  to  support  separate  certification  efforts  (e.g.,  GENSEk-only, 
CSSCS-only) . 

9.1.6  The  contractor  shall  develop  a  certification  test  plan  to 
facilitate  the  certification  of  the  I-S/A  AMPE  Prototype  and  Test 
Facility  and  the  follow-on  Software  Support  Facility  (SSF). 

9.2  Facil ity  Accreditation  Test  Plan.  The  contractor  shall  develop  a 

generic  Faci  1  ity  Accredi tatibri . Test  Plan  for  Governi.ient  approval.  Tne 

Facility  Accreditation  Test  Plan  shall  be  a  subset  of  the  Certification 
Test  Plan  and  shall  verify  the  correct  installation  and  operation  of  an 
I-S/A  AMPE  at  each  facility. 

9.3  Facility  Accreditation  Support.  The  contractor  shall  provide 
technTcal  support  during  facility  accreditation  testing  when  requestea  by 
the  Government. 

9.4  Prototype  and  Test  Facility  Accreditation  Test  Plan.  The  contractor 
shall  deveTop  a  Prototype  and  Test  Facility  Accreditation  Test  Plan  for 
Government  approval.  The  Prototype  and  Test  Facility  Accreditation  Test 
Plan  shall  be  a  subset  of  the  Certification  Test  Plan  and  shall  verify 
the  corre.t  instillation  and  operation  of  the  t-S/A  AMPE  Prototype  and 
Test  Facility  and  the  follow-on  SSF. 

9.5  Pro  to  type  and  Test  Facj^ljty  Accreditation  Support.  The  contractor 
shall  provide'  tecTinical  support  dunn^  the  Prototype  and  Test  Facility 
accreditation  testing  and  during  accrecitation  testin^j  of  tne  follow-on 
SSF  when  requested  by  the  Government. 
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ACCREDITATIO,\  AUTHORITIES 


10.1  General .  Completion  of  a  systein  evaluation  and  certif icatiot)  does  not 
constitute  accreditation  for  the  system  to  be  used  in  an  operational 
environiiient .  Certification  provides  a  technical  evaluation,  alonij  with 
supportini^  data,  which  describes  the  system's  security  strengths  and 
weaknesses.  Evaluations  which  lead  to  the  certification  recoiritnendations  will 
be  based  on  this  document  and  the  Trusted  Computer  System  Evaluation.  Criteria 
for  Class  Al .  The  accreditation  procedures  found  in  DODD  C-5030.58  or  its 
successor  document  (IAS  Network  Telecommunications  Security  Certification 
Manual)  and  DOD  C-5030.58M  will  be  followed  before  the  system  can  be  approved 
for  use  in  processing  or  handling  classified  information. 

10.2  Designated  Approving  Authorities.  The  following  organizations  are  the 
Designated  Approving  Authorities  (DAA)  for  the  specified  classified 
processing  areas. 


Security  Area 


DAA 


Defense  Special  Security  Communications  National  Security  Agency 
System/Critical  Intelligence  Communic¬ 
ations 

Defense  Special  Security  Communications  Defense  Intelligence  Agency 
System^Special  Intelligence  Communic¬ 
ations 

Single  Integrated  Operation  Plan/  Oryar.ization  of  tiic  Joint  Cniefs 

Extremely  Sensitive  Information  of  Staff 

General  Service  Defense  Communications  Agency 
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MAINTENAN’CE 


11.1  Security  Configuration  Management.  Strict  configuration  controls 
shall  Be“Tp^TT^^To”TrrTcFT!T7TPCTT7  and  CPCs  throughout  the  design 
and  development  process,  and  shall  continue  throughout  the  operational 
life  of  the  system  in  accordance  with  MIL-STD  483. 

11.1.1  The  security  configuration  controls  developed  for  the  TCB  shall 
specifically  address  the  following  areas: 

a.  TCB  Development  System 

( 1 )  Hardware 

(2)  Software 

(3)  Systeih  documentation 

b.  TCC  System  Deliverables 

(1)  Hardware  components 

(2)  All  TCB  and  untrusted  software  components 

(3)  Design  and  analyses  documentation 

c.  TCB  Test  Deliverables 

(1)  Test  plans  and  procedures 

(2)  Test  data 

11.1.2  During  development  and  maintenance  of  the  TCB,  a  security 
configuration  management  system  shall  control  tne  following: 

a.  Formal  security  model  development 

b.  Formal  logic  representation  (e.g.,  PDL) 

c.  Implementation  documentation 

d.  Source  language  statements 

e.  Operational  version  of  the  object  code 

f.  Test  fixtures 

g.  Documentation 

h.  Hardware  components 

i.  Software  Support  Environment  (e.g.  compiler) 
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n.1.3  The  confiijuration  management  system  shall  ensure  a  consistent 
correspondence  between  all  of  the  docuti.entation  and  software  and  hardware 
associated  with  the  current  baseline  version  of  tne  system.  The  selected 
configuration  management  system  shall  support  audits  of  cnanges  to  the 
basel ine. 

11.1.4  Capabilities  shall  be  provided  for  generating  a  new  version  of 
the  system  from  source  language  statements.  The  configu’'jition  management 
system  shall  provide  a  complete  audit  including  reference  to  the 
requirement,  designer,  coder,  date  and  time  of  each  revision  of  the 
source  language. 

11.1.5  Capabilities  shall  be  available  for  comparing  the  newly  generated 
version  with  the  previous  version  of  the  system  at  the  source  language 
statment  and  object  code  levels.  The  results  of  the  comparison  shall  be 
auditable. 

11.1.6  A  trusted  facility  for  system  control  and  distribution  shall  be 
provided  for  maintaining  the  integrity  of  the  mapping  between  master 
library  documentaton  and  the  master  copy  of  the  source  language  stateiiient 
for  the  current  baselined  version. 

11.1.7  All  material  used  to  generate  the  TCB  shall  be  protected  against 
unauthorized  modification. 

11.1.8  The  contractor  shall  provide  to  the  Government  recommended 
configuration  management  procedures  for  auditing  "as  installed"  security 
paratneters  (e.g.,  terminal  security  level)  for  a  site  and  all  subsequetit 
changes  to  that  site  baseline. 


OPERATIONAL  FACILITY  SECURITY 


12.1  Operational  Site  Security  Documentation. 

12.1.1  The  contractor  shall  develop  and  submit  to  the  Government  for 
approval  a  site  manual  that  describes  the  operator  and  security 
administrator  functions  relateu  to  security  includincj  chan9ini^  security 
characteristics  and  examining  and  maintaining  audit  files.  Tne  manual 
shall  provide  guidelines  for  the  consistent  and  effective  use  of  the 
protection  features  of  the  system,  how  they  interact,  how  to  generate  a 
secure  system,  and  cautions  regarding  countermeasures  for  known  flaws. 

The  manual  shall  include  cautions  about  functions  and  privileges  that 
must  be  controlled  in  a  secure  facility. 

12.1.1.1  A  separate  manual  or  section  shall  address  guidelines  fur 
securely  interacting  with  the  system. 

12.1.1.2  A  separate  manual  or  section  shall  provide  instructions  on  lijw 
to  identify  and  handle  failed  components  that  may  contain  classified 
information . 

12.1.2  The  contractor  shall  submit  to  the  Government  for  approval 
procedures  for  packing,  shipping,  repair,  storage,  and  handling  of  failea 
components  that  may  contain  classified  infor.iiation  (e.g.,  disposal  of 
memory  boards). 

12.1.3  The  contractor  shall  develop  a  description  of  expected  System 
reaction  to  security-related  events  (e.g.,  access  violations, 
security-related  failures,  etc.}.  This  information  will  be  used  by  tne 
Government  to  develop  security  procedure  documentation  for  system  support 
personnel  and  penetration  tests. 
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DESCRIPT icr;  OF  SNAPS 


SASIC  DATA 
AUTODIN  TRAFFIC 


A  S .  0  1 

a.  E?.co  a  "’essacp  is  orocess^'i  i"^o,  throii'ah,  and  o'lt  of  the  ressaae 
switching  unit  of  a  DCS  AUTOOIN  Switchina  Center  (ASC),  an  entry  is  made  on  a 
disc  and  in  Journal /Hi  story .  This  entrv  consists  of  routina  indicators,  time 
of  file,  time  of  entry  into  the  ASC,  time  of  start  of  message  out,  time  of 
exit  from  the  ASC,  the  precedence  category,  and  other  operational,  statistical 
and  manacerial  information  about  the  messaae.  Most  o-^  these  items,  or  the 
nu’"e’"ical  difference  between  two  items  are  used  in  traf^^ic  enaineerina, 

b.  The  numerical  information  associated  with  a  single  messane  has  no 

0  r.o "!  n  i  nc  merit.  of  this  fset  mp<<:;appc  tn  hp  Droc^sspd 

befo>"e  sufficient  information  is  available  to  determine  averaae  values  for 
each  item  of  in'^erest,  e.q.,  averaqe  messaae  lennth,  Tno  time  reauired  to 
gather  a  sufficient  number  of  individual  values  to  aet  a  true  averaae  is 
orohibitive.  The  field  of  mathematical  statistics  has  developed  practical 
concepts  and  procedures  of  samplina.  These  concepts  use  a  small  section  of 
the  total  data  available,  and  from  this  data  sample,  determine  the  average 
values.  The  OCA-developed  Switch  Networks  Automatic  Profile  Svstem  (SNAPS)  is 
based  on  a  sampling  conceot  and  is  the  primary  source  of  data  used  in  traffic 
engineering. 

40. 1  Data  Reoii irements 

a.  Traffic  volume  is  the  major  determininq  factor  in  the  design  of  a 
communications  system.  The  traffic  volume  in  line  blocks  (84  characters),  for 
a  specified  time  Period,  is  determined  approximately  by  multiplyinq  the  number 
of  messages  transmitted  during  this  time  period  by  the  averaqe  message  lenoth 
expressed  in  line  blocks.  Traffic  volume  is  not  a  constant.  It  varies  from 
time  period  to  time  period.  Busy  periods  are  those  time  periods  during  which 
the  most  traffic  is  being  processed.  Generally,  in  traffic  enqineerina 
applications,  the  busy  period  values  are  used  in  the  calculations.  Variations 
in  traffic  volume  are  caused  by  variations  in  the  message  lengths,  as  'well  as, 
the  rate  of  message  transmission.  Averaae  message  lenaths  are  determined  by 
dividing  the  total  number  of  line  blocks  by  the  total  number  of  messages  in  a 
specified  time  period.  The  duration  of  the  time  period  used  is  the  total  time 
of  the  samplina  oeriod. 

b.  Using  orecedence  categories  is  a  wav  o'"  indicatina  the  relative 
imoortance  of  messages.  The  orecedence  categories  in  the  AUTODIN  are:  (1) 

ECP  and  CRITIC,  (2)  Flash,  {3)  Immediate,  M)  Priority,  and  ('^)  Routine,  the 
order  of  transmission  is  first-in,  first-cut  (FIFn)  <'or  each  precedence 
category,  with  all  of  the  messages  of  •''igher  orecedence  being  transmitted 


before  the  next  lower  precedence  cn  each  AST  cutout  channel.  An  ECP  or  CPITIC 
ressaGe  will  interrupt  a  messaae  of  1  ov/er  precedence  to  allow  the  ECP  or 
'RITIC  '"essaae  to  be  transmitted  i^rnediatel  v.  A  Flash  '^essaae  will  inter>"upt 
a  '"essace  of  lowe*"  precedence  to  al''cw  the  Flash  "’essaqe  to  be  transmitted 
i-^Tediately.  CFITIC  will  not  interruot  an  EC?  nor  will  an  EC?  interrupt  a 
CRI'IC.  An  Immediate  O'^ecede'^ce  messane  will  not  interrupt  a  messaae  of  lower 
precedence  in  the  process  of  transmission:  but,  upon  completion  of  the  lower 
precedence  mess='n^,  th-:’  I'^mediate  crecedence  •^essaoes  will  be  the  noxt  to  be 

c.  ~he  rii^oe''  and  1  enath  of  •^essaces  by  pr=>ceGence  cateaorv,  as  well  as, 
the  total  nu'^ber  o'  messaaes  and  the  averaae  lenath  of  the  messaae,  are  needed 
to  help  determine  the  effective  transmission  rate  reouired  to  ensure  that 
speed  of  service  objectives,  as  specified  in  ACP  121,  and  DCAC  310-130-2,  and 
discussed  in  TEP,  Volume  XII,  Section  3,  are  met. 

d.  Tlie  traffic  engineer,  in  determinina  the  homina  assianment  of 
s.^PSC'^ibers,  should  know  the  community  of  interest  of  the  subscriber.  That 
is:  does  the  subscriber  primarilv  receive  from  and  transmit  to  a  certain  set 
of  stations?  Are  these  stations  homed  on  the  same  ASC? 

e.  Associated  with  community  of  interests  are  destination  and  collective 
routine.  Destination  routina  reauires  that  each  addressee  be  separately 
listed  in  the  messaae  header;  collective  routing  reauires  that  a  sinale 
routina  indicator  be  used  for  a  group  of  addressees.  The  ASC  has  tables  of 
collective  routina  indicators  (CPIs)  which,  in  turn,  list  the  actual 
address-^es.  Tne  ASC  will  then  send  the  messaoe  to  each  station  indicated  bv 
the  parti cul ar  CRI . 

f.  3y  usina  a  series  of  data  ^rom  previously  produced  reports,  the  values 
of  each  of  the  above  factors  mav  be  Plotted  aaainst  time.  These  plots  will 
show  the  trend  of  the  factor  with  time;  e.o.,  increasina,  no  sianificant 
change,  or  decreasing.  These  trends  may  then  be  extended  into  the  near  futur^^ 
to  aive  forecast  values  for  each  of  the  plotted  factors. 

g.  The  above  numerical  factors,  when  combined  with  the  svstem  facilities 
data  (see  Traffic  Enqine'^rina  Practices  (TEP),  Volume  IX,  Basic  Data,  Section 
3,  AUTODIM  Facilities),  describe  the  capabilities  of  the  system  as  well  as 
what  the  system  was  doina  at  the  time  the  numerical  information  was 
collected.  These  descriptions  make  up  the  network/switch  profiles. 

h.  Using  the  traffic  volume  to  be  processed  and  the  speed  of  transmission 
of  a  circuit  as  entries,  the  ETR  may  be  determined  by  referring  to  the  trunk 
capacitv  curves  in  TEP,  Volume  XII,  Estimatina  Facilitv  Quantities,  Section  B, 
Curves  and  Tables. 

AQ. 2  Data  Sources 

a.  Traffic  data  is  of  two  types:  (1)  measures  and  (?)  calculated  from 
measured  data.  Examples  of  each  type  of  da.ta  are  presented  in  the  DCA  Switch 
Networks  Automatic  Profile  Svstem  (S’iAPS),  which  was  developed 
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by  CCA  to  oresen-.  Tost  of  the  traffic  info'^etinn  needed  by  ^he  traffic 
eno'neer.  Veasu''ed  data  are  i  te-^s  such  as  th'^  Time  o^  File  fTOF),  the  niimber 
of  line  blocks,  ‘■’’e  tirre  of  Start  of  r'essaee  In  (SOV  PI),  and  the  tim>=>  of  Znd 
O'  "’essaae  Out  tl"''  OUT'.  Calculated  data  are  items  such  as  averaae  iressaae 
lencth,  processina  t  me,  and  handlina  tine. 

b.  SNAPS  pmcesses  data  which  has  been  extracted  from  the  discs,  and 
Ccurna  1/Historv  tapes  at  each  swi'ch.  Instead  of  usina  the  i 'i^op’’ai' ion  for 
“^ach  da^/  of  the  ~cnth,  a  sarnie  period  is  used. 

c.  "^.is  sai'ole  period  is  the  ^irst  r'ursday  of  each  ■'onth  unless  the 
orecedinq  Tues^'av  or  the  followino  Friday  is  a  holiday,  in  which  case  the 
sample  period  is  the  second  Thursday.  The  same  sample  period  is  used  at  all 
switches. 

AO.  P.eports 

a.  SNAPS  consists  of  five  reports:  (1)  Switch  Profile,  (2)  Network 
Profile,  (3)  ECP-SPECAT  Subscriber  Report,  fd)  Soeed  of  Service  Analysis,  and 
(5)  Svstem  Soeed  of  Service  bv  Time  Intervals.  Reoort  1  is  subdivided  into 
three  sections.  Section  I  consists  of  static  facilities  information  which  is 
explained  in  Basic  Data,  TEP,  Volume  IX,  AUTODIN  Facilities,  Section  3, 
Paraaraoh  9-301, 2a,  Section  II  consists  of  traffic  measurements  for  each  ASC, 
which  are  divided  by  types  of  traffic:  i.e.,  teletypewriter,  data  pattern,  and 
maqnetic  tape.  Under  each  type  of  traffic,  the  measurements  are  fur^-.he'" 
subdivided  by  precedence,  security,  number  of  destinations,  messace  lenqth  by 
precedence,  and  in-station  processina  time  parameters.  Section  III  Provides 
traffic  distribution  information  bv  time  and  destination.  This  same  basic 
format  is  followed  for  report  2.  System  traffic  orocessinq  infornation  is 
presented  in  reports  3,  4,  and  5. 

b.  Description  of  SNAPS  Printouts. 

(1)  SNAPS,  Report  1,  Switch  Profile,  Section  II,  this  section  of  the 
SNAPS  printout  describes  the  total  traffic  volume  using  the  parameters  of 
trunk  traffic,  terminal  traffic,  Lancuage  Vedi a  Formats,  send/receive  traffic, 
precedence,  security,  and  number  of  destinations.  The  first  subsection  of  the 
printout  describes  the  terminal  traffic  in  terms  of  message  lenaths,  send  and 
receive,  and  in-station  processina  time.  Trunk  traffic  is  described  in  the 
second  subsection. 

(2)  SNAPS,  Peoort  1,  Switch  Profile,  Section  III.  Section  III  gives 
traffic  distribution  by  2-hour  periods  and  the  speed  of  service  by  switch. 

(3)  SNAPS,  Peport  2,  DCS  Network  Profile,  Section  II.  Section  II  of 
the  DCS  N’etwork  Profile  presents  the  traffic  volume  distribution  of  the  DCS 
AUTODIN.  The  total  volume  of  traffic,  in  the  number  of  messaaes  and  line 
blocks  is  described  by  lanauage  media  format,  terminals,  precedence  cateaory, 
security  level,  number  of  destinations  oer  message,  messaae  lenaths,  and 
average  in-station  processing  time. 
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(4)  S'.’APS,  ReDort  2,  DCS  'letwork  Profile,  Section  III,  Subsection  A, 
Actual  I'' ‘■^'’-Svvi  tch  Tru'^k  Lo'cina.  This  subsection  oresents  the  distributiO’^ 
of  tv-affic  in  nuT.ber  of  '^essaaes  and  line  blocks  transmitted  between  directly 
connected  ASCs . 

(5)  SidAPS,  P,eDO''t  2,  DCS  Network  Profile,  Section  III,  Subsection  B, 
"^raffic  Distribution  Between  ASCs.  "^his  subsection  oresents  the  di stf^ibution 
of  traffic  in  nurber  of  ress^'ces  ana  linebl'ck  transmitted  from  an  o**:  c. 'at  i  nc 
to  a  destination  nSC. 

(6)  SNAPS,  Report  2,  DCS  Network  Profile,  Section  II,  Subsection  C, 
Soeed  of  Service,  Average  fessaae  Lenoth  by  Areas  and  Precedence.  This  SNAPS 
printout  presents  the  distribution  of  traffic  by  OCA  area,  averaae  message 
length,  and  Speed  of  Service  by  Precedence.  Time  is  oresented  in  tv/o 
categori es: 

1.  Time  0*  AL'TODI'!  En’-.rv  to  Time  AUTCOI'I  Exit. 

2.  Time  of  AUTODIN  Entry  to  Time  of  P.eceiot  at  Last  ASC. 

(7)  SNAPS,  Peoort  3,  ECp  -  SPE^AT  Subscriber  Reoort.  This  SNAPS 
orintout  presents  a  list  of  the  ECP-SPECAT  messaces  oriainated  and  delivered 
durina  the  sa'^ole  period.  Speed  of  Service  is  oresented  in  3  onriods: 

Time  1  refers  to  elaosed  ti"'p  hetwnen  Time-o^-File  and 

Start-of-Messaf’e  In  into  AUTOOIN. 

Time  2  refers  to  elaosed  time  between  Start-of-'''essage  In  into 

AUTODIN  and  End-of-N'essaae  Out  at  last  ASC. 

Time  3  refers  to  elapsed  time  between  Time-of-Rile  and  End-of-'-lessaae 

Ou t  at  1 ast  ASC. 

(8)  SNAPS,  Reoort  A,  Soeed  of  Service  (SOS)  Analysis.  Th^s  SNAPS 
printout  lists  those  high  orecedence  messaaes  (Flash  Override,  Flash  and 
Immediate),  which  were  not  processed  within  established  thresholds.  Speed  of 
Service  is  presented  in  3  periods  for  each  precedence. 

FI  ash  Overri  dg_  and  FI  ash 

SCSI;  The  elapsed  minutes  between  Time  of  File  and 
End-of-i'lessaae-Out  Time. 

Threshold  set  for  this  study:  10--MIN 

S0S2:  The  elapsed  minutes  between  System- In  time  and 
End-of-Messaae-Out  ’’’ime. 

Threshold  set  for  this  study:  5--i*'IN 

S0S3:  The  elaosed  minutes  between  System- In  time  and 
End-of-f-’essaae- In  Time. 

Threshold  set  for  this  s^udy:  3--MIN 


ate 


SOS'!;  "^rie  elapsed  ’"Ir'ites  bet'.veen  Ti'^e  of  File  ard 
Erd-O"!^-/ ess  aae- 'u  t 
'OareshoUi  set  for  this  studv; 

S0S2;  The,  elaosed  'ei'^utes  bet'.-.'een  Systeei-Io  Ti^^e  and 
End-of-'''essaae-^’jt  Time. 

Threshold  set  for  this  stLidv; 

S0S3;  Toe  el  acsed  'ninutes  between  Syste"’-In  Ti-’e  ant 
End-of-Messaqe- In  Time. 

Threshold  set  for  this  study;  S--'TIN 

(9)  SNAPS,  Report  5,  Systesi  Speed  of  Service  by  Time  Intervals. 

This  subsection,  presents  the  averaae  speed  of  service  in  minutes  by  precedence 
catenory  for  all  messaoes  ente'^ed  into  the  DCS  AUTODIN.  It  also  p;"esents  the 
distribution  of  messages  by  precedence  cateaory  by  soeed  of  service  ranaes. 

The  speed  of  service  is  determined  in  two  v/avs;  (1)  The  time  elaosed  from  the 
time  of  the  DCS  AUTODIN  entry  to  the  time  of  the  DCS  AUTODIM  exit,  and  (2)  The 
time  elapsed  from  the  time  of  file  (TOF)  to  the  time  of  the  DCS  AUTODIN  exit. 

c.  Other  Sources  of  Traffic  Enaineering  Data. 

(1)  OCA  Circular  310-D70-30.  This  DCA  Circular  describes  the  type, 
format,  and  freouency  of  reports  reauired  to  supply  the  information  needed  to 
direct  and  manaae  the  DCS  AUTODIM.  Some  of  the  information  is  directly 
applicable  to  traffic  engineerina.  The  followina  paraaraphs  will  identifv  the 
reports  that  contain  traffic  enaineering  data  and  will  qive  examples  to  show 
where  in  the  report  the  data  is  located. 

(a)  General.  Each  ASC  has  the  capahilitv  to  process  the 
history  tapes  in  an  off-line  mode  to  generate  statistical  information. 

(b)  Monthlv  ASC  Sumary.  This  report  is  to  be  received  at 
Headquarters,  DCA  not  later  than  5  workina  days  after  the  end  of  the  month  in 
the  format  as  shown  in  DCAC  310-070-30,  Chapter  fi. 

(c)  Header  Extract  Report.  This  shows  the  distribution  of 
traffic  for  each  channel,  send  and  i^oceive,  by  ASC  Routing  Indicator.  DCAC 
310-D70-30,  Chapter  6. 

40.3  Collection  Methods 


a.  General,  '^any  of  the  real-time,  on-line,  automatical  1 v  qenerated  DCS 
AUTODIN  reports  have  little  or  no  impact  on  traffic  enqineerino.  Most  of  the 
reports  are  either  operational  or  manaoerial.  Most  of  the  data  needed  for  use 
in  traffic  enaineering  is  presented  in  DCS  SNAPS  reports,  but  some  useful  data 
is  available  from  other  sources.  The  following  paraqraph  outline  how  these 
data  are  obtained. 
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b.  "eader'  Extract  °roar3n.  This  is  an  off-1  if^e  procrar.  that  is  used  at 
•^acn  ASC  to  develop  the  data  base  for  a  1-day  monthly  sanolina  period.  This 
sample  day  is  the  ‘i-'St  '’nursdav  of  the  '"onth,  unless  the  preceedina  ~ues 
the  followina  ‘^''■dav  is  a  holidav,  in  .-.hich  case  the  sar^o'’^'  day  is  ''  w 
late*".  The  Header  Extract  Program  extracts  data  from  the  discs  and 
Oournal/Hi  story  tapes  and  w»'ites  this  data  on  maonetic  taoe.  The  magnetic 
tape  aenei^ated  by  ‘-.he  -eader  Extract  Proaram  is  used  for  input  to  the  CPA 
Sh-PS  oroara'".  The  maanetic  tape  ^or  SMAPS  is  sent  by  aii — ail  to  Di'^‘-cto’^. 
CCii,  ATTh:  Code  Em5'’i,2Sl),  '..'ashi noton,  D.C.  E'^E'^E. 


a)  fx 
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STATISTICS  AMD  REPORT  GEMEP-ATICM  CRITERIA 


A.  Generally  stated,  the  philosophy  upon  vhich  the  ,V1?E  Statistics  and 
Report  Generation  fanction  of  this  appendix  is  based  is  that  if  system 
performance  indicators,  both  historical  and  real-time,  can  be  easily 
accessed,  displayed,  printed  and  subjected  to  near  real-time  statistical 
analysis  under  AMPE  operator  control,  then  the  need  for  periodic, 
■■■olum.inous  .VIPE  nistorical  and  statistical  reports  for  use  at  local, 
natv;or<,  and  intervening  levels  of  management  will  be  substantially 
reduced.  To  attain  a  system  with  these  attributes  requires  that  the  a;-1?E 
system  record  the  data  ele.ments  specified  in  this  appendix  in  an  easily 
accessible  manner  and  that  a  versatile  Report  Generator  Program  (RG?)  be 
developed  which  can  access  these  data  elements  and  perform  the  many 
functions  specified  in  section  3  of  this  appendix.  Although  the  RGP  is  a 
complex  program,  the  intent  is  to  have  a  highly  functional  program 
available  when  needed,  but  invoke  its  use  sparingly  and  lim.it  the 
information  and  data  processing  requirements  to  the  mini.mum  essential 
elements  necessary. 

The  three  standard  A.MPE  management  and  status  reports,  the  DCS 
Message  Quality  Control  Report,  the  circuit  and  Equipment  Outage  Report 
and  the  Terminal  Capacity  Report  supplemented  by  a  Message  traffic 
summary  report  should  provide  sufficient  information  as  to  the 
acceptability  of  AMPE  performance.  Should  problems  with  system 
performance  be  encountered,  the  real  time  aspect  of  the  RG?  would  be 
employed  to  request  data  and  assist  in  the  analysis  of  the  data  to 
support  a  quick  identification  and  resolution  of  the  problem  area.  The 
one-time  cost  of  developing  the  RGP  as  specified  herein,  should  result  in 
staff-hour  savings  by  permitting  operator  and  management  personnel  to 
obtain  specific  items  of  information  quickly  to  support  timely 
decision-making  without  resorting  to  time  consuming  analysis  of 
voluminous,  comprehensive  printouts  and  reports. 

The  AMPE  system  shall  support  the  preparation  of  system  status  and 
statistical  reports  as  required  by  Function  1.16.  These  reports  will  be 
generated  from  a  wide  range  of  data  elements  which  shall  be  recorded  and 
maintained  by  the  system.  The  requirement  for  the  AMPE  to  record  and 
maintain  these  data  elements  derives  not  only  from  Function  1.16, 
Statistical  and  Statistical  Report  Generation,  but  also  from  other 
functions  such  as  Function  1.8,  History  Logs  and  Files.  It  is  therefore, 
important  that  the  recording  of  the  data  elements  be  accomplished  in  an 
efficient  and  well  organized  manner, i.e.,  a  data  base,  to  which  the 
Report  Generator  Program  (RGP)  shall  have  ready  access. 

The  RG?  function  shall  be  designed  to  support  two  broad  categories  of 
reports  and  displays.  The  first  category  is  that  of  User  Site/System 
Control  reports  and  displays  which  are,  in  general,  current  system  status 
information  and  short  terra  system  performance  statistical  reports.  These 
User  Site/System  Control  Reports  will  include  both  automatically 
generated  displays  and  reports  and  operator  requested  displays  and 
reports,  and  are  used  principally  for  new  time  site  and  system  control 
functions . 
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The  .second  category,  Network  Statistical  Management  reports,  are  generally 
less  .'oncerned  with  real-time  equipment  states,  keva.i  more  to  a'.^erage 
performance  iigares  over  specified  periods  of  time  and  also  to  peak 
conditions  at  key  network  elements  (e.g.,  peat  traffic  through  an  XMPE 
daring  the  busiest  hour  of  the  month,  largest  backlog  of  messages  on  queue 
i-aring  the  month).  These  reports  tend  to  require  much  more  computer 


:c3S--.ing  oewer  since  t.ne''  iriVOi.ve  t.ne 


;licaticn  of  statistical 


-.-?rat*ons  to  a  large  number  of  data  elaments.  The  aspect  of  the  RG? 
supporting  the  preparation  of  t.nese  reports  would  be  a  background  or 
off-line  type  of  operation,  and  must  be  extremely  flexible  to  permit  the 
network  managers  to  obtain  the  analyses  necessary  to  solve  the  wide  range 
of  management  situations  likely  to  occur  in  a  network  with  the  large 
number  of  AMPEs  expected  to  be  fielded. 

3.  To  support  the  required  statistics  and  report  generations  (both 
Site, System  control  and  Network  Statistical  Management  reports)  the 
following  set  of  data  elements  must  be  recorded  and  maintained  and 
available  for  retrieval,  manipulation,  and  formatting  by  the  RGP: 

1,  Each  message  transiting  the  system  shall  have  the  following  data 
elements  generated  or  extracted  from  the  m.essage  and  recorded: 

a.  Coirmunity  (R  or  y) 


Precedence 

Language  Media  Format  (for  send  and  receive) 

Classification  (to  include  TCC,  TRC  and  SHD) 

Content  Indicator  Code  (CIC) /Comununications  Action  Identifier 
-  (CAI) 

Originating  Station  Routing  Indicator  (OSRI) 

Originating  Station  Serial  Number  (OSSN) 

Time  of  File  (TOF) 

Date  Time  Group  (DTG)  (if  present) 

Time  of  Delivery  (TOD)  to  each  station 

Line  number  of  any  unsuccessful  delivery  attempt 

Channel  Designator  and  sequence  number  under  which  the  system 
received  the  message  (from  connected  Mode  II,  Mode  V,  and  Mode 
I  TI  line  users) 


m.  Number  of  characters  and  lineblocks  in  the  message 

n.  Incoming  line  number  from  which  the  system  received  the 
message  (from  the  network) 


o.  Day  and  tiae  niessage  was  originally  received  in  the  system 
(Time  of  Receipt  (TCR]) 

p.  History  file  Number 

a.  Delivery  Channel  Designator  and  Channel  Sequence  Number  for 
Mode  IIS,  Mode  Vs  and  Mode  Is  using  TIs. 

r.  Destination  Routing  Indicator (s) 

з.  SSIC  only  in  Format  Line  12 

t.  System  Generated  Unique  Message  Identifier  (UMI) 

и.  Message  Format  Type 

V.  Operator  ID  Number  (s)  if  message  was  intervened 

w.  Time  of  Transition  from  Queue  to  Queue  (input  to  output,  etc.) 

2.  For  each  peripheral/terminal  (channel),  the  system  shall  have  the 
following  data  elements  generated  and  recorded: 

a.  Time  of  each  connection  (log-on) 

b.  Identification  (ID  number),  [channel  and/or  jack  number] 

c.  Highest  classification  channel  can  accept  (to  include  TCC's, 
TRC's  and  SHD's) 

d.  Language  Media  Forraat(s)  (LMF)  it  can  process 

e.  Restoration  priority 

f.  Amount  of  traffic  on  queue  at  time  of  log-on 

g.  Time  of  each  disconnection  (log-off) 

h.  Amount  of  traffic  on  queue  at  time  of  disconnection 

i.  Disposition  (Altroute)  instructions  in  force 

3.  The  following  system  performance  data  elements  shall  be 
generatedand  maintained: 

a.  Number  of  system  restarts  and  reloads 

b.  Number  of  successful  and  unsuccessful  peripheral  accesses,  for 
the  current  RADAY. 

c.  Processor  idle  time 

d.  Listing  of  all  message  retrieval  requests  to  include; 
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(1)  Requesting  tertiinaL/stacion  ID  number 

(2)  dumber  of  messages  per  request 

(3)  Date  and  time  of  request 

e.  Listing  of  each  channel/Iine/tr unk  outage  occurence  to  incLude: 

(1)  Channel  line  trunk  ID  number 

(2)  Time  logged  out 

(3)  Time  logged  back  to  service 

(4)  Reason  for  Outage  (RFO)  Code  (to  be  assigned  by  the  AMPE 
operator  when  determined) 

f.  Listing  of  occurences  of  message  rejections  to  include: 

(1)  Source  terminal/station  ID  number 

(2)  Date  and  time  of  occurence 

(3)  Terminal/position  ID  number  to  which  the  message  was 
rejected  for  correction/service 

(4)  Whether  message  was  rejected  automatically  to  service  or 
manually 

(5)  Reason  for  Rejection  code  (assigned  automatically  by  AMPE 
when  possible  or  by  AMPE  operator) 

4.  Any  other  data  elements  required  to  support  generation  of 

Site/System  Control  Reports  and  displays  (Section  C) .  Network 
Statistical  Management  Reports  (Section  D) ,  and  required 
preformatted  reports  (E)  . 

C.  The  following  data  elements  will  be  available  on  a  real-time  basis 
(without  having  to  use  background  or  off-line  capabilities  of  the  RGP)  to 
support  User  Site/System  control  reports  and  displays: 


1.  The  cumulative  total  of  messages  and  lineblocks  received  and 
transmitted  over  each  channel  during  the  current  RADAY  by: 

a.  Community 

b.  Channel 

c.  Precedence 

d.  Media 
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2.  The  cunnalative  total  of  m-assages  rejected  during  the  currenr 
RADAY  by: 

a.  Ccrrjaun  i  cy 

b.  Channel 

c.  Type  of  reject 

3-  Current  message  status: 

a.  Total  number  of  messages  and  lineblocks  on  each  queue  in  the 
AMPE,  expressed  both  in  actual  numbers  and  as  percentage  of 
the  total  capacity. 

b.  Total  number  of  messages  and  lineblocks  on  intercept  and 
overflow  storage,  expressed  both  in  actual  n'umbers  and  as 
percentage  of  the  total  capacity. 

c.  Numbers  of  messages  and  lineblocks  on  queue,  intercept,  and 
overflow  by  channel  number,  designation,  media,  and  precedence, 

d.  Any  channel  which  has  exceeded  it  predetermined 
message/lineblock  threshold  based  upon  bit  rate,  to  be 
reported  on  a  real  time  basis. 

e.  The  oldest  message  in  the  system,  the  oldest  message  on  each 
queue,  the  oldest  message  on  intercept,  and  the  oldest  message 
on  overflow,  identified  by  unique  message  identification  and 
time/cycle  of  entry  into  the  system;  also  to  be  available  on  a 
by-channel  basis. 

f.  The  number  of  messages  scrubbed  during  the  current  RADAY  by 
channel. 

g.  Number  of  message  retrievals  in  progress  by: 

(1)  Requesting  terminal/station  number 

(2)  Precedence 

(3)  Average  number  of  messages  specified  per  request  in 
progress 

h.  Number  of  messages  by  router  type  and  classification  awaiting 
manual  intervention. 

i.  Average  message  length  of  all  messages  received. 

4.  The  following  system  status  information  shall  be  generated  and 
maintained  and  available  on  a  real  time  basis. 

a.  The  configuration  of  the  AMPE  system  equipment  shall  be 
maintained  using  the  following  categories  of  status: 
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'1)  The  status  and  configuration  of  each  channel  (to 
include  all  input,  output  and  local  lines) 

(a)  Classification  including  TCC,  TRC  and  SHD 

(b)  Channel  designator  and  sequence  number  (if 
applicable ) 

( c  )  Li  ne  type 

(d)  Line  status 


(2)  Alternate  routes  in  effect  by  routing  indicator 

(3)  Intercepts  in  effect  by  routing  indicator 

(4)  Table  change  notices 

d.  Sef/ice  directory  information 

e.  Cumulative  number  of  blocks  reruns /retransmissions  (per 
channel  -  final  RADAY  count)  (counter  to  be  reset  to  tero 
at  the  start  of  each  RADAY) 


f.  Cumulative  number  of  security  errors,  e.g.,  mismatches  by 
channel  (counter  to  be  reset  to  zero  at  the  start  of  each 
RADAY) 

g.  Number  of  successful  and  unsuccessful  peripheral  accesses 
for  the  current  RADAY 


D.  The  following  data  elements,  information,  and  functions  will  be 
available  through  the  RGP  (using  the  background  or  off-line  capabilities 
of  the  RGP  if  required)  to  support  Network  statistical  Management  reports 

1.  The  following  Message  Input  Statistical  calculations  shall  be 
supported : 

a.  Number  and  average  length  of  messages  received  per  hour  of 
each  RADAY  for  periods  not  to  exceed  31  days  by: 


(1)  Community  (R  or  Y) 


■  Catin". 

Csncjnt  Iilicator  Code  ’  ZIZ)  'Corjntir.ications  Action 
liontifier  (CAI) 

.5)  Ijar.g'’aoe  ;'eiia  "o'.— Lit  .ZZ'.T) 

!  •' )  .’■iosoace  CL'pe 

(7)  Precedence 

b.  N'unber  and  percent  of  messages  received  above: 

(1)  Bearing  AMPE's  ser'/ice  RI 

(2)  Entered  through  VDT,  OCR  or  in  modified  ACP  126  iortnat 

(3)  Generated  by  the  AMPE 

(4)  '.vlnich  are  suspected  duplicates 

(5)  Of  each  LT'IF  format  (narrative,  card,  type) 

c.  Percent  of  RADAY  utilized  by  each  input  channel  using 
specified  line  speed  of  the  particular  channel 

d.  N’lnber  of  messages  and  lineblocks  from  the  DON 

e.  M’umber  of  messages  and  average  delay  time 

Che  following  Message  Processing  Statistical  calculations  shall  be 
supported  for  each  RADAY: 

a.  N'omber  of  messages  accepted 

b.  Number  and  average  processing  time  of  messages  processed  by 
precedence  per  hour  of  each  RADAY 

c.  N’lmber  of  messages  rejected  by  type  (k,j,...) 

(1)  Automatically  to  ser'/ice 

(2)  Manually 

d.  N'lmber  of  messages  requiring  manual  inter'/ention ,  includes 
both  operator  intervened  and  system  rejected  messages 

e.  ^.'umber  of  messages  in  error  by  correction  line 

f.  ^Jumber  of  lines  corrected  by  line  t'/pe  code 

g.  N’'amber  of  messages  journaled  per  unit  time 
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a.  ■.-■'act'  ar.u  Isr.-gcfi  of  ressiaes  t;r'aris.::i cica  .ica’"  rar  aacn 

i\r^ur^  {  y  ' 

^1;  Cnannel 
U  J1  ass  i  r  c a:  Kn 
\Z)  Oesiinatlon 

(“)  Language  .veaia  Format  (ljXF) 

(5)  Message  t^pe 
[c.)  i\arrat1ve 
(a)  Data 

(cj  Service 
(,o)  Magnetic  tape 

(6)  Preceaence 

b.  Percent  of  RmDAY  utilizea  by  each  output  channel  (basec  on 
line  speed  of  each  cnannel) 

c.  Amount  of  delay  in  making  delivery  for  each  message 
transmitted  (i.e.,  time  of  transmission  minus  tim.e  of  receipt) 

The  following  Message  Distribution  Statistical  calculation  shall 
be  supported  for  eacn  RADAY; 

a.  Number  of  messages  oelivereo  Over-the-Counter  (OTC) 

b.  Number  of  messages  delivered  OTC  by  receiving  organization 
which  received  office  code  distribution: 

(1)  via  manual  assignment 

(2)  via  subject  code 

(3)  via  flagword 

(4)  via  reference 

c.  Numiber  of  messages  delivered  OTC  which  received  Protect 
Distribution  by  receiving  organization 

0.  N'umber  or  messages  and  copies  of  messages  oelivereo  OTC  to 
each  receiving  organization  by  classification 


e.  Total  number  of  copies  delivered  OTC  for  each  classification 


.'.^sSiiOc  StoZ^iS  Sr3cis^1csr  Av0rjj0  'Ti^ii'c^r  or  'r0ssoc“S  oy 
jc^CcCencc  anc  Li'.F  in  1110  Ccr  nnir  ci  ic  ui 

SYSGE'.,  not  :o  exccea  ;:  -a..s)  :o: 

3.  Inpui  queue 

b.  Processing  cueue 

c.  'jucput  Oucue 

G.  Intercept  queue 
e.  Overflow  queue 

E.  In  aaaition  to  the  above  requirement  for  oata  element  generation  and 
maintenance,  Site/System  Control  reports,  ana  Network  Statistical  Language 
reports,  following  specific  reports  must  be  prerormattec ,  automatical ly 
generatea  (in  real-time),  ana  printec  cut,  stored,  aisplayec,  and/or 
transmittea  (in  message  format  when  applicaole): 

1.  DCS  Message  Quality  Control  Peport.  Statistics  on  messages 
rejectee  for  specified  reason  codes  and  other  data  necessary  to 
implement  the  DCA  '-.essage  Quality  Program  as  prescribed  cy  ACP  121 
'JS  SUPP-1. 

2.  Circuit  and  Equipment  Outage  Report.  In  its  capacity  as  a  DCS 
Reporting  Station,  the  ARiPE  will  report  AMPE  system,  equipment, 
networK  ans  subscriber  channel  outages  to  OCA  IA',<  DCAC  310-55-1. 

To  the  maximum  extent  possiole,  55-1  reporting  must  be  automated. 

Outage  data  m.ust  oe  collected  and  accumulated  and  reports 
formatted,  generated  and  transmitted  in  message  format.  Only  the 
"S"  (Station)  "U"  (User)  line  reports  require  automatic  generation 
for  transmission. 

3.  Termination  Capacity  Report.  In  order  to  maintain  network 

conf igutation  control,  specifically  as  pertains  to  sizing,  traffic 
engineering  and  user  acess,  the  AMPE  shall  be  capable  of  providing 
the  status  of  termination/access  capacity  in  terms  of  AMPE 
limiting  factors,  e.g.,  software,  memory,  hardware  ana  throughput 
as  determined  by  AMPE  design.  This  report  shall  be  forwarded  via 
message  to  DCA  as  provided  for  under  OCA  Circular  instructions. 

F.  The  Statistical  Analysis/Report  Generation  Program  shall  be  compatible 
with  tne  AMPE  message  processing  software  package.  This  program  shall  be 
designed  to  perform  the  on-line  functions  specified  in  this  appendix  ana 
also  to  operate  in  a  background  mode  as  prescribed  for  the  majority  of  tne 
statistical  analysis  operations.  The  program  shall  be  designed  to  use  the 

recorded  data  elements  specified  in  this  appendix  and  shall  be  designed  j 

for  utilization  on  a  non-interference  basis  with  the  message  processing 
function  on  the  mMPE.  It  shall  provide  the  following  capaoility  to  the  | 

AMPE  operator;  I 

1.  The  AMPE  operator  shall  be  provided  the  capability  to  design  ana 
specify  the  contents  (configuration)  of  a  report  to  include  any 
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So-iel  C7  ca:a  elec-r.is  'isiea  in  paraaraph  A  r.iu-cucn  c  acove. 


of  aaca  e'.e'reris  in  a  report  snail  oe  selecLable  ana 
in  j  oraer  s^eci'iea  'a_y  t'la  mi*. PE  apc>  aaar. 

3.  Tne  AMPE  snail  De  capaole  or  storing  at  least  ten  report  fonr.ats 
as  specifiec  c>  the  AMPE  operator.  Each  report  snail  oe  capable 
or  oeing  speciriea  to  contain  all  aaaa  elements,  eacn  aata  element 
lO  oe  aijOiajca/preseii.-ca  iii  etfer_/  pessi..jle  ccfr.-;ii'iaiii'. n  ar  its 

5 S  j C C  i  5  ~  c'vi  p  ira;.’6  S  ^  ^  »  I  *'  cTc  S Ti a  i  i  36  ilO  i  ’i  i  *  t  j:  C  1  Cr,  Of*  t.> *c 

'iL;'::!:acr  or  aaia  6]er:efUs  znai  can  ot  incorpuraceo  inco  a  repert 
except  tnao  tnere  snail  oe  no  auplication  of  a  cata  eieirient 
dssignea  a  repetitive  set  of  parameters ) . 

A.  Storea-fannat  reports  or  single  aata  elements  shall  be  capable  of 
being  requestea  througn  the  AMPE  operator  ana  celivered  to 
specifiea  ren.ote  net.vcriv  control  station(s). 


5.  The  Ai'PE  operator  shall  nave  tne  capaoility  to  cesicn  ana 
commana-generate  a  report  from,  a  cesignatea  operator's  console. 

6.  Tne  report  generation  module  (software  routine)  shall  permit  tne 
report  prograinmer  to  insert  up  to  fifty  (50)  lines  of 
comitencs/reniarKS  witnin  tne  heading  ana  body  of  the  report. 

7.  Tne  report  generation  moaule  shall  proviae  all  operator  prompts 
necessary  to  permit  the  operator  to  design  the  report. 

c.  The  AMPE  system  shall  support  the  loading  of  preformattea  report 
specifications,  up  to  the  limits  establishea  for  store-foixiat 
reports  in  paragrapn  D.3  above,  at  System  Generation  time. 

9.  The  report  generator  shall  proviae  tne  capability  to  selectively 
compute,  summarize  and  analyze  the  selected  data  elements.  The 
report  generator  snail  be  capable  of  operating  on  any  of  the  data 
elements  listed  in  paragraphs  A  through  E.  For  example,  the 
report  generator  shall  be  able  to  compute,  sort  and  display/print 
out  the  following  typical  analysis  products: 

a.  Compute  the  time  in  station  for  each  message  (time  of  arrival 
-  time  of  delivery),  sum.marize/sort  by  precedence,  compute 
mean  and  standard  deviation;  also  tim.e  for  last  ZDK 
retransmission . 


b.  Compute  the  time  in  station  for  each  message,  summarize/sort 
by  destination  channel 

c.  Summarize  by  precedence,  classification  and  source  channel, 
the  num.ber  of  messages  transmitted  and  received 

d.  Summarize  by  source  and  destination  channel,  the  numoer  of 
packets  and  lineolocxs  received  and  transmitted 
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1 . 1  Scope 


The  I-S/A  A.VPE  will  be  an  element  of  the  Integratea  AUTUDIll  System,  (IAS), 
to  satisfy  various  Military  Service  ana  Defense  Agency  communications 
recuirements  at  tne  base/camp/post/staticn  level  and  also  to  Serve  as  as  a 
functional  repiacenent  for  tne  m'OTUDIA  Switching  Centers  (ASCs).  These 
applications  create  a  need  for  the  I-S/A  AMPE  to  interface  with  DCS 
racilities,  tactical  ano  allied  switched  and  data  terminal  racilities.  This 
Interface  Control  Document  (ICO)  includes  environmental,  mechanical, 
electrical,  protocol/format  and  human  interface  criteria  controlling  or 
constraining  the  development  of  the  I-S/A  AMPE. 

1 . 2  Standard  Definitions  and  Terminology 

Definitions  for  the  technical  terms  used  will  be  found  in  the  I-S/A  AMPE 
Functional  Requirements  Description  (FRD)  Section  10.0. 
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2.0  APPLICABLE  DOCUMENTS 


2.1  Militiarv  ani  Federal  Standards 


rED-STD-1003 


Teleconnunications ,  Synchronous  Bit  Oriented  Data 
Link  Control  Procedures  (Advanced  Data 
Communications  Control  Procedures ) 


FED-STD-1031 


Telecommunications,  General  P'arpose  37  Position  and 
9  Position  Interface  Between  Data  Terminal 
Equipment  and  Data  Circuit  Terminal  Equipment 


MIL-STD-188C 


Military  Communication  System  Technical  Standards. 


MIL-STD-188-100 


Common  Long  Haul  and  Tactical  Communication  System 
Technical  Standards 


MIL-STD-188-114 


Electrical  Characteristics  of  Digital  Interface 
Circuits 


MIL-STD-195 


Marking  of  Connections  for  Electronic  Assemblies 


MIL-STD-454 


MIL-STD-461 


MIL-STD-781C 


MIL-STD-1472B 


MIL-P-7788 


Standard  General  Requirements  for  Electronic 
Equipment 

Electromagnetic  Interference  Characteristics 
Requirements  for  Equipment 

Reliability  Tests  Exponential  Distribution 

Human  Engineering  Design  Criteria  for  Military 
Systems,  Equipment  and  Facilities 

Panels,  Information,  Integrally  Illuminated 


MIL-H-232 


MIL-H-46855B 


(C)  RED/BLACK  Engineering  -  Installation  Guidelines 
(U) 

Human  Engineering  Design  Criteria  for  .Military 
Systems,  Equipment  and  Facilities 


2 . 2  Joint/Allied  Communications  Publications 

ACP  121,  US  SUPP  1  (C)  Communications  Instructions  -  General  (U) 


AC?  127,  US  SUP  1 
&  NATO  SUP  3 

(C)  Communications  Instructions  -  Tape  Relay 
Procedures  (U) 

JANA?  123'  ) 

Automatic  Digital  Networ’-c  (AUTODIN)  Operating 

Proce  dures 

DOI-103 

(Confidential  Compartmented  Document)  Defense 

Special  Security  Communications  System  Operating 
Instructions,  System/Data  Procedures  (U) 

Ser-.'ice  ’Agency  TelecoHi-T.unications  Instructions  and  Procedures 

AFNAG-9A 

Using  NACSEM  Documents  and  TEMPEST  Emanations  Limits 

DCAC  370-D175-1 

DCS  AUTODIN  Interface  and  Control  Criteria,  Revised 
Draft  Attached 

DCAC  370-D195-1 

Test  and  Evaluation,  DCS  AUTODIN  Interface, 

Category  I  Testing 

DCAC  370-D195-2 

Test  and  Eh/aluations ,  DCS  AUTODIN  TEMPEST  Category 

II  Testing 

DCAC  370-D195-3 

DCS  AUTODIN  Category  III,  Operational  Acceptance 

Test 

DCAC  370-V175-6 

AUTOVON  System  Interface  Criteria 

NTP-4(  ) 

Naval  Telecommunications  Publication  4 

Industry  Speci f ications  ,  Instructions  and  Manuals 

ANS  X3. 28,  1976 

Establishment  and  Termination  Control  Procedures 

CCITT  Recommendation 

X.  25 

Interface  Between  Data  Terminal  Equipment 

(DTE)  and  Data  Circuit  Terminating  Equipment  (DCE) 

for  Terminals  Operating  in  the  Packet  Mode  on 

Public  Data  Networks,  CCITT  1976,  revised  February 
1980. 

EIA-RS232C 

Interface  Between  Data  Terminal  Equipment  and  Data 
Communications  Equipment  Einploying  Serial  Binary 

Data  Interchange 

EIA-RS-449 

General  Purpose  37-Position  and  9-Position 

Interface  For  Data  Terminal  Equipment  and  Data 
Circuit  Terminating  Equipment  Employing  Serial 

Binary  Data  Interchange 

I3M  BISYN’C  IBM  Corporation  Order  Mo.  GA27-3004-2  10/70,  Binary 

Synchronous  Conrnunication 

MACSE.M  5100  (C)  Compromising  Emanations  Laboratory  Tear 

Standards  Electromagnetics  (U) 

MACSEM  5200  (S)  Compromising  Emanations  Design  Handbook  for 

Mon-Cryptographic  Equipment  (U) 

References 

a.  MARDAC,  Document  Mumber  85  C1002,  FD-01,  "Local  Digital  Message 
Exchange/Remote  Interface  Exchange  Terminal  Interface,  (RIXT)"  dated 
July  1979. 

b.  CCTC  Technical  Memo  TM  173-78,  "AUTODIM-™mcCS  Direct  Access 
Communications  Module"  (DIMDAC)  TR-01  dated  30  June  1979. 

c.  MAVAL  COMMAND  SYSTEM  SUPPORT  ACTIVITY  Technical  Report  "MAVCOMM 
Communication  Line  Protocol"  NAVCOSSACT  Document  Mo.  85P012A  TR-05 
dated  Feb  1975. 

d.  UNIVAC  Publication  UP-7532,  "DCT  2000  Programmers  Reference"  revised 
May  6,  1969. 

e.  DARPA  Report  DoD  Standard  Internet  Protocol,  January  1980. 

f.  DARPA  Report  DoD  Standard  Transmission  Control  Protocol,  September 
1981. 

g.  DCA  Code  532,  "NICS  TARE  AUTODIM  Interface  Device",  September  1979. 

h.  TRI-TAC  Interface  Control  Document,  ICD-015. 

i.  Defense  Data  Network  Program  Plan,  January  1982  with  changes. 

j.  Draft  AUTODIN  I  System  Function  Specification,  DCA  B650,  August  1982. 


3.0  PHYSICrL  CHARACTERISTICS 


3 . 1  Operator  S^steM  Lavoui 

The  I-S/'m  A.TPE  system,  equipnent,  and  facilities  shall  be  designeo  and 
installed  to  provioe  wopk  environments  which  foster  effective  procecures,  work 
patterns,  and  personnel  safety,  and  which  minimize  discomfort,  Cistraction, 
and  any  ether  factors  .wiich  degraoe  human  performance  or  increase  tne 
prooaoility  of  error.  Layout  of  equipment  shall  also  be  directed  toward 
minimizing  personnel  ano  training  requirements  witnin  tne  limits  of  time, 
cost,  and  performance  tradeoffs.  Controls,  displays,  marking,  cooing, 
labeling,  ano  arrangement  schemes  (equipment  and  panel  layout)  snail  be 
uniform  for  common  functions  of  all  equipments.  MIL-STO- 1472B  shall  be  used 
as  a  guide. 

3.2  Healtn  ano  Safety  Criteria 


During  I-S/A  Ai>iPE  design,  health  ano  safety  factors  should  be  given  najor 
consideration  to  acnieve  safe,  reliable,  and  effective  performance  by 
operator,  maintenance,  ano  control  personnel,  ano  to  optimize  personnel  skill 
requirements  ano  training  time.  The  I-S/A  AMPE  shall  meet  requirements  of 
;'U>.-H-A6855B  and  MIu-STD- 1472B  in  applying  health  ano  safety  design  criteria. 

3.3  Environmental  Conoitions 

3.3.1  Operating  Temperature  ana  Humidity 

The  I-S/A  Ai'iPE  shall  be  capable  of  operating  without  degradation  within  a 
temperature  range  of  15°  to  30°C,  40%  to  60%  relative  humidity, 
ncn-conoens ing,  at  altituoes  from  sea  level  to  10,000  feet. 

3.3.2  Non-Operating  Temperature  and  Humidity 

The  I-S/A  AiVPE  shall  be  capable  of  being  storeo  or  transported  within  a 
temperature  range  of  -10°  to  +55°C,  at  10%  to  90%  humidity,  non-condensing,  at 
altitudes  from  sea  level  to  15,000  feet,  without  affecting  operational 
performance . 

3.3.3  Noise 

Acoustical  noise  generated  by  the  I-S/A  AMPE  shall  be  controlled  in 
accordance  with  paragraph  5. 8. 3. 3. 2  of  MIL-STD-1472B.  Individual  and 
collective  equipment  noise  shall  not  exceed  65  db(A).  Acoustical  energy  shall 
not  be  concentrated  in  narrow  banowidths  approximating  a  pure  tone  (5  db  above 
neighboring  frequency  bands). 

3.3.4  Vibration 

Vibration  requirements  shall  be  as  specified  in  MIL-STD-781C,  paragraph 
50.1.3,  which  tests  the  equipment  with  the  mild  vibration  normally  experienced 
in  the  ousiness  office-type  env ironm,ent,  ano  vibration  that  is  normally 
experienced  during  maintenance.  In  addition,  see  MIL-STD-1472B,  paragraph 

5. 8. 4. 2  which  refers  to  Equipment  Vibrations. 
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3.4  Physical  Criteria 


3.4.1  Si ze 

Physical  size  of  the  I-S/A  h,VPE  ana  its  peripheral  aevices  shall  be 
cesignea  and  constructeo  to  not  exceed  the  size  of  coirparaole  equipments 
Qevelcpeo  for  conmercial  applications.  Due  to  the  v.ioe  variety  of  existing 
facilities  in  '.-.hich  tiie  I-S/A  m!-/PE  must  oe  installeo,  the  equipment  size  must 
oe  limiteo.  Equipu.ent  components  for  snipping  ana  installation  must  be 
smaller  tnan  34"'x  X  30"!  X  96"h.  ms  installed,  tne  equipment  ano  its  required 
cooling  area  above  the  equipment  must  be  no  higher  than  84". 

3.4.2  /<ei  ght 

Weignt  requirements  of  the  I-S/A  AMPE  shall  not  exceeo  a  floor  loading  of 
1000  pounds  point  load  ana  250  pounds  per  square  foot  cistributea. 

3.4.3  Maintenance  Access 

I-S/A  Ai'iPE  design  ana  construction  shall  proviae  reaaily  accessible  test 
points  throughout  the  equipment  to  allow  rapid  evaluation  of  equipinent 
performance.  Hardware  subsystems  le.g.,  power  supplies,  logic)  shall  be 
readily  removable  with  the  use  of  a  minimum  of  effort;  tools,  if  required. 
Shall  be  common  hand  tools  normally  carried  by  maintainers ;  cables  shall  be 
plug  ana  socxet,  quick  aisconnect,  no  terminal  strips  snail  be  used,  where 
required,  maintenance  adjustments  shall  be  reaaily  accessible  ana  easily 
iaentified.  The  need  for  special  tools  or  equipment  must  be  justified. 
Maintenance  access  to  the  interior  shall  be  from  the  front  and/or  rear  with 
all  components  readily  accessible.  Trouble  shooting  shall  be  facilitated 
througn  tne  use  of  passive  extender  boards  and  cables. 

3.5  Electromagnetic  Interference/Compatibility  (EHI/EMC) 


The  I-S/A  AMPE  equipment  shall  operate  compatibly  within  its  RF 
environment.  Equipment  for  both  secure  and  nonsecure  applications  shall  meet 
the  electromagnetic  emission  and  susceptibility  requirements  included  in  table 
4-1  of  MIL-STD-461B  and  Test  Methods  described  in  MIL-STD-462.  The  "limited" 
requirements  listed  in  table  4-1  shall  be  applied,  including  CS09.  The 
following  additional  details  of  the  requirements  are  provided: 

(a)  Signal  and  control  leads  shall  be  included  in  CEOl  and  CE03 

tests . 

(b)  Air  Force  and  Navy  requirements  shall  be  used  for  CS06 

tests . 

(c)  Minimum  sensitivity  within  the  I-S/A  AMPE  equipment  shall 
establish  the  testing  sensitivity.  If  this  cannot  be  determined,  1  millivolt 
shal 1  be  used. 


(d)  RSOl  requirements  shall  be  applied,  use  AF  and  Navy 
requirements  for  RS02,  part  1. 


in  tne 


^e)  The  limits  for  RS03  shall  oe  as  shown  for  "all  otncr  sites" 
table  shown  in  paracrapn  19.2  of  ML-STD-4olB. 

3 .6  TEl-PEST 

Tne  I-S/n  Al-PE  shall  oe  TERPEST  conpliant  in  accordance  with  iifl.CSE!-',  5100. 
Testing  for  compliance  shall  be  in  accordance  witn  the  current  ve''sicti  of  DCA 
Circular  370-D195-2. 

3.7  Electrical  brcuncinc 

The  I-S/A  AMPE  shall  con:ply  .vitn  MIL-STD- 1S8- .24,  Grounding,  Bending  and 
Snielding  for  Conimon  Long  Haul/Tactical  Conmunications  Systems  and  shall  have 
provisions  for  bonding  the  units  to  the  green  wire  ground  in  accordance  witn 
l•UL-hDBK-232,  RED/BLACK  Engineering-Installation  Guidelines. 

3.3  Power  Reg ui remen ts 

The  I-S/A  AMPE,  to  induce  the  entire  facility,  shall  operate  on  120  or 
203  VmC,  oO  Hz.  Tiiere  snail  oe  an  option  available  for  220/380  volts  or 
440/415  volts,  50  Hz  wnere  required  by  the  available  power  rrecuency.  ’"he 
internal  power  supplies  shall  provide  filtering  so  transients  of  less  than 
■^IGii,  -20‘/o  in  voltage  or  +10"  in  rrequency  lasting  less  than  500  milliseconds 
shall  not  cause  failures. 

3 . 9  HEMP  Protection 

The  I-S/A  AMPE  hardware  shall  nave  HEMP  protection  in  the  form  of 
Electro-magnetic  shielding  and  line  isolation  and  surge  protection. 
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4.0  PROTOCOLS  nCu  FOR^./^TS 


4 , 1  Protocol  Hierarchical  Lavers 


For  the  pcrposes  of  this  document,  a  protocol  is  defined  to  oe  a  set  of 
rules  governing  the  formats  ana  procedures  used  for  communication  oetv/een  t.vo 
cooperating  modules.  Protocols  operate  at  man>  aifrerent  levels  of  the 
communications  process,  ranging  from  physical  connection  ana  electrical 
signals  on  a  simple  link  to  the  hign-level  interaction  among  users  anc 
processes  across  several  net.vorKS. 

The  concept  or  protocol  layering  has  been  incorporatea  in  the  development 
of  most  current  data  network  protocols.  However,  these  efforts  have  tenceo  to 
oe  based  on  different  layering  concepts  and  definitions.  Tne  International 
Standards  Organization  (ISO)  and  the  American  national  Standards  Institute 
(AMSI)  nave  been  col  1 aoorating  to  alleviate  tnis  problem  by  oeveloping  a 
standard  reference  mocel  of  a  nierarcrical  layering  of  communications 
protocols.  Subsequently  Defense  Advanced  Research  Projects  Agency  (OARPA) 
proposed  an  adaptation  which  has  been  adopted  for  the  I-S/A  AMPE. 

The  architecture  proposed  for  this  reference  model  (Figure  1)  consists  of 
seven  independent  layers,  and  is  included  here  to  put  the  I-S/A  AMPE  protocols 
in  perspective.  Each  protocol  layer  accesses  the  services  of  the  layer  below, 
performs  a  well-oefinea  function  aided  by  those  services,  and,  in  turn, 
provides  services  to  the  layer  above  it.  An  important  property  of  tnis 
hierarchical  structure  is  that  for  any  given  protocol  layer,  the  structure  of 
the  layers  below  it  appears  transparent,  i.e.,  each  layer  is  aware  only  of  the 
services  of  the  layer  immediately  below,  regardless  of  which  lower  layer 
actually  performs  tne  service.  The  relationship  between  protocols  in  adjacent 
layers  is  called  an  interface.  Thus,  the  interactions  among  protocols  in 
different  layers  are  defined  by  the  interfaces  between  layers. 

The  seven  layers  in  the  reference  model  are  defined  as  follows; 

Level  1  -  Physical  Control,  concerns  the  mechanical  construction  of 
physical  connections  and  the  actual  electrical  means  of  bit 
transmission  across  a  physical  medium. 

Level  2  -  Link  Control,  enables  logical  sequences  of  messages  to  be 
exchanged  across  a  single  physical  data  link. 

Level  3  -  Network  Control,  provides  logical  channels  capable  of 
transferring  information  between  two  endpoints  in  a  single 
communication  network. 

Level  4  -  Internet  Control,  provides  the  necessary  protocol 
constructs  so  that,  in  conjunction  with  a  gateway, 
intercommunications  between  disjoint  packet  networks  using  different 
pn,,-.GCols  at  Levels  1,  2  and  3,  e.g.,  between  the  DDN  and  an  X.25 
-  'rerciai  networx,  can  be  achieved. 
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FIGURE  1.  SEVEN  LAYER  PROTOCOL  MODEL 


Level  5  -  Transport  Ena-to-Eno  Control,  provides  reliable  ena-tc-ena 
transport  of  messages  across  an  arbitrary  topological  configuration, 
possibly  through  several  interconnected  netv.ori<s. 

Level  6  -  Utility  Control,  proviaes  interpretation  of  the  information 
excnanged . 

Level  7  -  Application,  is  the  level  of  the  subscriber  or 
communicating  process  itself. 

4.2  Protocols 


The  protocols  that  shall  be  implemented  in  the  I-S/A  AI-iPE  are  as  specified 
herein.  Anile  the  ISO  model  has  been  adapted  by  tne  IAS,  tne  IAS  protocols  do 
i\0T  map  directly  to  the  ISO  model,  therefore  do  not  read  any  significance 
into,  e.g.,  TCP  being  labeled  "Session  Layer,"  as  none  is  intended. 


The  physical  level  shall  provide  bit  serial  and  cnaracter  serial 
electrically  coded  outputs.  Both  asynchronous,  synchronous,  and  isochronous 
interfaces  shall  be  provided.  As  a  minimum,  each  interface  shall  provide  for 
data  transfer,  status,  and  control  signalling  necessary  to  meet  the 
performance  characteristics  defined  in  this  specification.  The  functional  and 
mechanical  characteristics  of  the  digital  interface  circuits  between  the  I-S/A 
AMPE  and  terminals  or  network  elements  shall  conform  to  the  requirements  of 
Federal  Standard  1031  (FED-STD-1031 ).  The  electrical  characteristics  snail 
conform  to  MIL-STD- 188- 1 14.  FED-STD-1031  specifies  the  interface  between  Data 
Terminal  Equipment  (DTE)  and  Data  Communications  Equipment  (DCE).  Figure  2 
Shall  be  considered  the  schematic  for  defining  the  standard  interface  between 
uTE  and  DCE.  Applicable  DTE/DCE  include  teletypewriters,  data  terminals,  the 
DC  side  of  signal  conversion  (MODEM)  equipment,  both  terminal  and  line  side  of 
cryptographic  or  cryptographic  control  equipment,  digitized  voice  equipment, 
and  remotely  operated  equipment  where  the  interface  is  at  the  DC  baseband. 
Interoperability  shall  be  provided  between  I-S/A  AMPE  equipment  designed  to 
conform  to  FED-STD-1031  and  MIL-STD-188- 1 14  and  older  equipment  designed  to 
conform  to  the  EIA  Standard  RS-232C  and  MIL-STD- 1S8C.  FED-STD-1031  and 
MIL-STO-188-1 14  do  not  specify  other  characteristics  of  the  DTE/DCE  interface, 
such  as  signal  quality  and  clock/data  phase  relationship,  essential  for 
satisfactory  operation  of  the  interconnected  equipments.  These 
characteristics  are  described  in  MIL-STD-188-100  and  the  I-S/A  AMPE  electrical 
interfaces  shall  conform  to  the  requirements  of  this  document. 


4.2.2  Link  Layer 

4.2.2. 1  IAS  Standard  Link  Protocols 
a.  DCS  Mode  I 


DCS  Mode  I  is  a  full  duplex,  character-oriented,  synchronous 
operation  with  automatic  error  and  channel  controls  allowing  independent  and 
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simuJcaneoLS  tv/O-.-.aj'  operation.  In  aadition,  Mooe  I  uses  character  parity  anc 
block  parity  checking  along  with  retransmission  of  errored  blocks  to  achieve 
an  automatic  error  cetection  and  correction  capaoility.  The  terminal  responos 
automatical  ly  to  control  characters  by  continuing  or  stopping  transi..ission  or 
aisplaying  action  information  to  a  human  operator.  uCS  Mode  I  shall  be 
supportec  as  oescribec  in  CCA  Circular  370-0175-1  and  Reference  2.5.j.  The 
mecnanical  and  electrical  interface  for  DCS  Mode  I  shall  conform  to 
F'5D-ST0-1031 . 

Tne  allc.'.'aole  transmission  speeds  snail  oe: 

75  X  2**n  bits/sec 
n=0, 1 ,2,3,4,5,6,7 

Tne  AMPE  shall  be  capable  of  supporting  an  effective  transfer  rate  of 
at  least  90%  for  each  Mode  I  access  line  connected.  As  a  minimum,  the  AMPE 
snail  be  Capaole  of  accepting  an  SOH  prior  to  acknowledging  receipt  of  an  EOM 
without  losing  message  accountability. 

b .  DCS  Mooe  IB 

OCA  Mode  15  shall  be  implemented  as  specified  in  Appendix  A. 

Tne  speeos  for  DCS  >iOde  IB  shall  be  a.  75  X  2**n  bits/sec 

n=l ,2, 3, 4, 5, 6, 7 

b.  110  bits/sec 


c.  DCS  Mooe  II 

Mode  II  is  a  full-duplex  asynchronous  operation  allowing  simultaneous 
two-way  operation  without  automatic  error  and  channel  controls.  It  shall  be 
supported  as  specified  in  DCA  Circular  DCAC  370-D175-1  and  Reference  2.5.3. 

d.  DCS  Mode  V 


DCS  Mode  V  is  a  full  duplex  asynchronous  operation  allowing 
independent  and  simultaneous  two-way  transmission  with  limited  channel  and 
error  controls.  DCS  Mode  V  shall  be  supported  as  described  in  DCA  Circular 
DCAC  370-D175-1  and  Reference  2.5.j. 

e.  ADCCP 

Advanced  Data  Comimunications  Control  Procedures  (ADCCP)  is  a 
bit-oriented,  synchronous  link  control  procedure  and  shall  be  supported  as 
described  in  FED-STD-1003.  The  speeos  for  ADCCP  shall  be: 

75  X  2**n  oits/sec  where  n=3,4,5,6,7. 

This  is  a  post  IOC  item.  The  protocol  will  be  defined  in  greater  detail  at 
tinie  of  implementation. 
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f .  CCITT  X.^5 

The  I-S/A  m.'vPE  shall  iaipleinent  link  access  prccedcres  (LAPS)  as 
specifiec  in  InLernational  Telegraph  and  Telephone  Consultative  Cointti  ttee 
^CCITT)  r^econinencation  X.25  -  Interface  oetween  Data  Terminal  Equipment  (DTE) 
and  uata  Circuit  Terminating  Equipment  (DCE)  for  Terminals  operating  in  trie 
Packet  Mode  on  Public  Data  Networks,  CCITT  1975,  revised  February  1930. 

4.C.2.2  'Jser  Lnique  LinK  Protocols 


The  user  unique  link  protocols  described  nerein  shall  oe  iTiplen^entec 
in  the  IOC  I-S/A  AMPE.  These  user  unique  protocols  shall  be  implemented  in  a 
modular  fashion  so  that  they  need  not  oe  implemented  in  every  I-S/A  AMPE  ano 
may  be  removed  as  appropriate  in  the  future. 

a .  Army  AMPE-MART  Interface  Requirements 

The  Army  AMPE-MmRT  interface,  including  the  SIDPERS  print  expansion 
requirements,  shall  be  implemented  as  specified  in  Appendix  B. 

b .  Army  IRT  Interface  Requirements 

The  Army  IRT  interface  shall  be  implemented  as  specified  in 
Appendix  C. 

c .  Army  DPI  Interface  Requirements 

The  Army  DPI  interface  including  the  Preamble  Format  requirements 
shall  be  implemented  as  specified  in  Appendix  0. 

d .  Navy  DCT  2000  Data  Communication  Terminal  Interface 

The  Navy  DCT  2000  interface  shall  be  implemented  as  specified  in 
Reference  2.5d. 

e .  Shore  Station  Message  Processing  Set  (SSMPS) 

Requirement  deleted  by  U.  S.  Navy. 

f .  Navy  Remote  Information  Exchange  Terminal  (RIXT) 

The  Navy  RIXT  interface  shall  be  implemented  as  specified  in 
Reference  2.5a. 

g.  World  Wide  Military  Command  and  Control  System  (WW'MCCS)  Computer 
Interfaces 


All  communications  with  the  Honeywell  H-6000  computer  used  by  the  WWMCCS 
must  pass  through  a  Datanet  335  (DN-355)  GE  Remote  Terminal  Supervisor 
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(GaTS).  In  orocr  to  pass  AU’^ODIfi  traffic  throogh  this  restrictive  iiiterface, 
three  "generic"  s^ste'rs  .'-ere  uevelopea  which  have  evolved  to  the  existing 
tnree  ,,.'.-'CCS  inter'ace  recu i ren'ients .  Eacn  consists  of  a  procedure  in  a 
prcct'uinrad le  oevicc  .in  line  oetween  an  ASu  and  a  DI.-355)  cooperating  witn  a 
procedure  in  tne  h-6oGu  to  ui'idge  the  Di\-55d.  Each  s>'Steir.  also  accomplishes 
message  foriTiatting,  and  performs  a  number  of  special  message  management 
functions  within  the  H-ouOO.  Provision  shall  be  ivaae  for  variation  within 
eacn  generic  interface  on  a  si te-o^'-si te  basis.  Tne  generic  w'.'.MCCS  interfaces 
are: 

,  1 )  MCCS  h/^TS  -  hACE  Protocol 


Tne  NACE  procedure  within  an  H-6000  communicates  (througii  tne  ON-355) 
with  the  hMCS  AUTOOIN  Terminal  Subsystem  (NATS)  proceoure  in  a  "Remote 
Computer"  that  is  connected  to  AUTOOIN.  "Remote  Computers"  presently  used  for 
that  function  include  the  AMME,  LCMX,  AFA^’PE,  Honeywell  H-716,  DCT-yOOO,  and 
tne  vnivac  1103.  It  is  intended  tnat  the  I-S/A  AMPE  interface  directly  with 
tne  Df.-355  as  the  "Reifote  Computer"  specified  in  the  protocol  in  Appenoix  F. 

(2)  A'JTOOIN-'wwMCCS  Direct  Access  Communications  Module  oINDAC)  Interface 


The  OINDAC  procedure,  implemented  on  the  Army  AMKE  and  Navy  LDMX, 
cominunicates  through  the  ON-355  and  the  OAC  to  TPAS,  a  procedure  implemented 
in  tne  wV^MCCS  H-6000.  The  I-S/A  AMPE  snail  interface  directly  to  the  DN-355, 
ana  communicate  with  the  TPAS  procedure  in  the  H-6000  using  the  protocol 
sppcifieo  in  References  2.5  b  ana  c. 

^ 3)  Remote  Terminal  Operating  System  (RTQS)  Interface 

RTOS  is  a  variation  of  NATS  implemented  on  the  DCT-9000  and  AFAiMPE. 
The  I-S/A  AMPE  interface  shall  be  directly  to  the  DN-355,  and  comimunicate  with 
tne  RTOS  procedure  in  the  H-6000  using  the  protocol  specified  in  Appendix  G. 

h .  OPINTEL  Fleet  Broadcast 

The  OPINTEL  Fleet  Broadcast  interface  will  be  implemented  Post  IOC. 
4.2.3  Network  Layer  -  CCITT  X.25 

The  I-S/A  AMPE  shall  implement  the  datagram  option  of  the  packet  level 
DTE/DCE  interface  as  specified  in  CCITT  X.25.  This  interfaces  to  the  Internet 
Protocol  in  the  internet  layer  (4.2.4)  and  to  LAPB  in  the  link  layer 
(4. 2. 2. If). 


Incernet  La^er  -  Internet  Protocol  (IP) 


Tne  DcD  Stancara  Interne!  Protocol  provioes  two  basic  services: 
accressing  ana  fragnientation .  The  protocol  is  aistributeo  among  hosts  and 
gutewa^s,  and  provioes  neitner  reliable  communication  nor  flow  control.  The 
basic  unit  of  data  excnangeo  between  protocol  modules  is  the  datagram,  wnich 
may  be  fragmenteo  for  transmission  tiirougn  "small  packet"  networks.  The  IP 
header  cefines  the  stancaro  format  for  tne  protocol.  The  IP  shall  be 
impleifientec  in  tiie  I-S/n  A.'-iPE  as  specified  in  DARPA,  DoD  Standaro  Internet 
Protocol,  January  19S0. 

4.2.5  Transport  Layer  -  Transmission  Control  Protocol  (TCP) 

Tne  DoD  Standard  Transmission  Control  Protocol  provioes  connection 
management,  reliable  data  transfer,  error  checking,  sequencing,  flow  control, 
process- level  aodressing,  and  multiplexing.  It  is  a  connection-oriented 
eno-to-eno  transport  protocol,  implemented  in  hosts.  The  TCP  shall  be 
implementeo  in  the  I-S/A  AMPE  as  specifieo  in  DARPA,  DoD  Stanoard  Transmission 
Control  Protocol,  January  1980. 

4.2.6  b'ti  1  i ty  Layer 

4.2.6. 1  Terminal-to-host  Protocol  (THP) 

The  Terminal-to-Host  Protocol  (THP)  is  a  Post-IOC  host-to-host  level 
network  protocol  that  is  required  in  order  that  terminals  whose  circuits  are 
terminated  on  IAS  elements  other  than  the  I-S/A  AHPE  (e.g.,  a  multilevel 
secure  Terminal  Access  Controller)  can  obtain  FMS  from  a  designated  I-S/A 
AMPE.  The  THP  to  be  used  in  the  I-S/A  AMPE  shall  be  the  TELNET  protocol. 

Post  IOC  ThP  will  be  used  to  allow  (1)  directly  connected  terminals  to  access 
other  network  elements  including  other  local  terminals,  and  (2)  remote 
terminals  to  access  the  I-S/A  AMPE  through  the  network.  It  supports  both 
terminal-to-terminal  and  terminal-to-process  transactions.  A  primary  function 
or  THP  is  to  present  a  standard  appearance  (called  the  Network  Virtual 
Terminal)  for  all  terminals  to  be  accessed  by  a  network  element. 

4. 2. 6. 2  Formal  Message  Protocol  (FMP) 

The  contractor  shall  design  and  implement  the  FMP  in  the  I-S/A  AMPE.  FMP 
is  a  network  protocol  that  shall  perform  control  ano  coordination  functions 
necessary  to  allow  exchange  of  formal  message  traffic  through  the  IAS 
networx.  The  FMP  shall  be  the  means  by  which  the  I-S/A  AMPE  can  reliably  and 
efficiently  transfer  messages  to  other  remote  I-S/A  AMPEs  for  eventual 
delivery  to  the  appropriate  addressees.  Similarly,  FMP  shall  accept  messages 
routed  to  the  I-S/A  AMPE  by  these  other  facilities  for  delivery  to  the  I-S/A 
AMPE  subscribers.  The  functions  performed  by  the  FMP  shall  consist  of  at 
least  the  fol lowing; 

a.  Accept  or  reject  delivery  responsibility  for  each  message 
received  and  notify  the  sender  of  the  message  of  such  acceptance  or  rejection. 
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b.  Perrorni  multiple  aacressed  message  routing  in  a  manner  which 
makes  efricient  use  of  tne  I-S/A  ANPE  ano  IAS  backbone  network  resources. 

c.  Ensure  networ<  level  message  alternate  routing  is  accoii.p  1  isned 
.'.hen  required. 

d.  Indicate  the  format  and  code  as  received  of  eacn  message 
transmitteo  (e.g.,  JAwmP-IZS,  COI-103  or  CkITIC). 

e.  Detect  lessage  looping  ano  siiuttling  (that  is,  messages  wtricn 
nave  traversed  tnis  I-S/A  APiPE  previous lyj.  Any  detected  messages  shall  be 
rejected  ano  tne  I-S/m  aMPE  operator  shall  be  notified. 

f.  Interface  with  the  set  of  routines/processes  that  constitute  the 

FMS. 

g.  Interface  with  the  TCP  (ICD  4.2.5). 

4.3  Formats 

The  I-S/A  AMPE  shall  support  the  message  formats  specified  herein. 

4.3.1  DP  Form  173 

DD  Form  173  is  a  message  preparation  form,  with  instructions  contained  in 
paragraphs  324  through  330  and  Annex  F  to  ACP-121  US  Supplement  1,  which  is 
used  to  prepare  messages  to  be  entered  into  the  I-S/A  AMPE  via  an  OCR  device. 

4.3.2  Mooified  ACP-126 

ACP-126,  Communications  Instruction  -  Teletypewriter  (Teleprinter) 
Procedures,  as  modified  by  Naval  Telecommunications  Publications  (NTP  4(  ), 

ICD  2.3),  paragraph  03,08,0500,  describes  formats  and  procedures  wnich  shall 
be  accommodated  by  the  I-S/A  AMPE, 

4.3.3  ACP-127 

ACP-127,  Communications  Instructions  -  Tape  Relay  Procedures,  with  U,S, 
Supplement  1  and  NATO  Supplement  3  describes  message  formats  and  procedures 
which  shall  be  accommodated  by  the  I-S/A  AMPE.  The  overall  document  shall  be 
useo  as  a  guide  and  in  addition  see  FRO  Taole  3,2, 1 ,2, 1 ,2-2  ACP-127/DOI  103 
Special,  Message  Processing  Requirements  for  the  specific  paragraphs  that 
shall  be  implemented  and  also  Reference  2,5,j, 

4.3.4  DO  I -103 

DOI-103,  DSSCS  Operating  Instruction,  System/Data  Proceoures,  describes 
message  formats  and  procedures  which  shall  be  accommodated  by  the  I-S/A  AMPE, 
The  specific  DSSCS  formats  that  shall  be  supported  as  specified  in  DOI  103  and 
Reference  2,5,j  are; 


a. 


:oi-io3 


b .  ^0I-1C3  Special 

c.  rtcbreviaCcc 
c.  CRITIC 

^  .  0  •  D  Onj'ir.i  “1^0 

oAi\AP-12S,  Auaon:atic  Jigital  Network  (AUTOOIii)  Operating  Procedures, 
describes  n.essage  formats  and  procedures  which  shall  be  accoimooateo  bv  the 
I-S/A  AMPE,  as  specified  by  Reference  2.5.j- 

4.3.6  Preamble  Format 

The  I-S/A  rtMPE  shall  provide  the  capability  to  process  data  received  over 
the  coiTimunication  line  interface  from  the  data  processing  installation  using 
the  inessage  preamole  in  lieu  of  a  JANAP  128  header.  Upon  receipt  of  a  message 
with  the  message  preamole,  the  I-S/A  AMPE  shall  create  a  CAhAP  128  formatted 
message  containing  text  headers  and/or  text  trailers  and  will  sectional ize  the 
message  as  required  by  communications  procedures  iSee  Appendix  D  ARMY  DPI 
Interface  Requirements). 

4.3.7.  Special  Format/Format  Conversion  Criteria: 

4. 3. 7.1.  Straggler  detection  variations  (input): 

a.  Allied/iNATO  Alliance  classmarked  channels:  If  received  from 
Allied/NATO  channels,  these  formats  undergo  no  straggler  detection 
processing.  Format  line  15,  if  present,  is  ignored. 

0.  General  Services  Administration  (GSA)  classmarked  channels  (JANAP 
128  format):  If  format  line  15  is  present,  normal  straggler  detection 
processing  shall  be  performed.  If  format  line  15  is  not  present,  no  straggler 
detection  processing  shall  be  performed.  In  either  case,  the  message  is 
marked  on  input  by  the  AMPE  as  a  GSA  originated  message.  This  marking  is  used 
only  if  the  message  undergoes  JANAP- to-ACP  format  conversion  for  output 
del ivery  (see  below) . 

4.3. 7.2.  Straggler  detection  variations  (output): 

a.  Allied/NATO  Alliance  classmarked  (ACP  127  format)  channel  methods 
of  straggler  detection.  Format  line  3  (DE  line)  processing  requires: 

(1)  NATO  channels:  To  give  each  message  delivered  the 
appearance  of  an  ACP  127  NATO  SUPP-3  formatted  message,  the  format  line  3  OSSN 
crosshatch  (?)  useo  for  normal  straggler  detection  processing,  if  present,  is 
removed  prior  to  output  delivery. 

(2)  Other  Allied  channels:  The  format  line  3  OSSN  crosshatch, 
if  present,  is  left  intact  for  output  delivery. 
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D.  When  GSA  originated  JANAP  12S  formatted  messages  (marked  on  input)  are 
to  oe  delivered  in  AGP  127  forirat  to  U.S.,  Allied  or  iNATO  channels,  the  format 
line  3  (OE  line)  built  by  the  Al-.PE  ^ill  not  include  the  straggler 

detection  crossnatcn  (=). 

d.j.7.3.  Output  Delivery  Prohibitions: 

a.  Delivery  of  Erlu-  security  level  messages  is  prohioitec  on 
-ilieo/.'iATO  Alliance  channels. 

b.  Delivery  of  messages  containing  CRIs  to  Allieo/RATO  Alliance  or 
^lolor.atio  Teleccnvunicaticns  Service  (STS'  cnaiinels  is  pronibitec. 

-.3. 7. A.  Output  transmission  ident i r icat ion  ^71)  line  (format  line  1, 
variations: 


a.  In  support  of  Allied/hATO  Alliance  requirements,  the 
AMPE -provided  output  TI  line  for  all  paper  tape  TI  line  user  channels 
(including  U.S.)  shall  oe  modified  to  terminate  with  5  spaces,  2CR,  ItF  vice 
tne  original  U.S.  termination  of  2CR,  ILF. 

b.  On  specifically  classmarKed  Allieo/hATO  Alliance  channels,  the 
output  TI  lire  shall  oe  terminated  in  one  of  tne  following  two  ways  depending 
cn  tne  security  classification  of  tre  m.cssage  oeing  celivered. 

(1)  5  spaces,  "LU",  2CR,  ILF  for  unclassified  messages. 

(2)  5  spaces,  "HH",  2CR,  1-F  for  messages  of  Restricted, 

Conf i centi al ,  Secret  or  Top  Secret  security  levels. 

4.3. 7.5.  Output  celivery  exceptions  for  GSA  classmarked  cnannels; 

a.  AMPE  system  generated  suspected  cuolicate  pilot  heacers  shall  not 
be  appended  to  messages  delivered  to  GSA  ciiannels. 

b.  Messages  originated  in  JAiNAP  128  format  with  input  LMF  codes  of  C 
(car'd)  or  A  (3- level  paper  tape)  undergo  no  format  or  media  conversion  cn 
Output  to  GSA  channels,  regardless  of  the  output  LMF  code  specified. 

4. 3. 7. 6.  Line  Code  Variations:  The  NICS/TARE  Network  will  use  ITA-5, 
employing  SI/SO  characters.  Consequently,  if  present  on  input,  the  AMPE  shall 
processes  ASCII  SI/SO  characters  as  unchanged  to  ASCII  (ITA-5)  output  channels 
and  as  LTRS/FIGS  to  Baudot  (ITA-2)  output  channels. 

4.4  Line  Character  Sets 


The  I-S/A  AMPE  shall  support  standard  and  user  unique  line  character 
sets.  In  the  IAS  system  all  standarc  line  transmission  is  in  the  bit  serial 
manner  with  two  codes,  ASCII  (ITA5  -  both  oco  and  even  parity)  and  Baudot 
(ITA2),  being  employed.  The  I-S/A  AMPE  shall  also  support  unique  line  cooes 
for  existing  terminals;  these  are:  BCD  and  uBCLiIC.  The  I-S/A  AMPE  snail, 
when  necessary,  perform  code  conversion;  e.g.,  ASCII  shall  be  converted  to 
Baudot  and  vice  versa  as  required  py  the  characte'^istics  of  the  sending  and 
receiving  termiinal.  The  coce  cnosen  for  line  transmission  on  any  given 
channel  is  totally  dependent  on  the  type  o*  terminal  equipment  anu  mcoe  or 
operation  employed.  The  code  conversion  software  shall  be  modular. 
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c.  For  trafric  originating  in  cara  format  or  3-ievel  paper  tape,  no 
forn.at  or  coce  conversion  ta^es  place  on  oucpot. 

c.  5-level  Code  on  inpot  is  al.'.a_,s  converted  to  8-level  Code  on 

0  (J  L  p  U  L  • 

5.1.2.1.d  .v'orlo  Uioe  Fiilitary  Command  and  Control  Sjstem  (W'v'MCCS) 

Interrace 

Tne  I-S/n  A.'-iPE  snail  provioe  Fi'',S  sopcort  to  tne  './.vMCCS  community,  via 
subscriber  interfaces,  some  of  wnich  require  unique  processing  in  accorcance 
.vitn  rererences  2.5b  ana  2.5c  and  Appenaices  F  and  G. 

5. 1.2. 2  Allied  Subscriber  Interfaces 

5. 1.2. 2.1  iNATQ  pMCS  TARE)  Interface 


Tne  contractor  snail  design  the  I-S/A  AMPE  to  interlace  with  the  IlATO 
(MCS  TAKE).  The  interface  for  the  AmTO  (i\ICS  TARE)  shall  oe  in  acccroance 
with  MI,.-ST0-138C  low  level  anc  in  accorcance  with  "Equipment  Specification 
for  MCS  TARE  AUTOuI'r  Interface  Device"  DCA  Coae  532,  September  1979.  The 
speeds  for  the  hATO  (MCS  TARE)  shall  oe  150,  30C,  oOO,  1200,  2400,  and  4800 
bps  selectaole.  Tne  aata  coae  for  the  MTO  (MCS  TmKE)  snail  be  ITA  ?5.  Khe 
a  MCS  TARE  interface  point  is  moved  from  a  closed  ASC  to  an  I-S/A  AMPE,  the 
AUTOCIfN  Interface  Device  (AID)  will  also  be  movea  to,  and  resiae  in,  that 
I-S/A  mIvPE  Facility.  MCS  TmRE  AID  size,  power  requirements,  electrical 
characteristics  ana  maintenance  cetails  will  be  provided  when  availaole. 

5. 1.2. 2. 2  Alliea  Subscriber  Formats 

Allied  subscribers  normally  will  exchange  traffic  with  the  I-S/A  AMPE  via 
the  ACP-127  format,  however  some  Allied  subscribers  do  use  the  JAiNAP-12S 
format.  Tnose  Alliea  subscribers  tnat  use  JANAP  128  format  shall  use  the 
Transmission  Release  Coae  (TRC)  on  all  messages. 

5 . 1 . 2 . 2 . 3  Austral i a/i<ew  Zealand  Interface 

In  the  transmission  iaentifier  (TI)  line  following  the  channel  sequence 
number  ana  5  spaces  the  classification  of  the  message  shall  be  indicated  by 
the  character  "UU"  for  unclassified  or  "HH"  for  all  levels  of  classifiea 
messages . 

5.1.3  Linked  Channels 


The  l-S/A  AMPE  shall  be  capable  of  providing  linked  channels  to 
subscribers,  'where  the  volume  of  traffic  between  the  I-S/A  AMPE  ana  a 
subscrioer  is  so  great  that  a  single  channel  cannot  provide  adequate  service 
without  delays,  aaditional  channels  are  proviaed  and  "linked"  to  the  first. 
Tnis  linking  is  a  program  convention  whereby  the  two  or  miore  cnannels  of  the 
link  are  treated  for  routing  purposes  as  a  single  channel,  'when  there  is 
message  traffic  for 


5.0  COMnliM CAT lOOS  IMERFACES 


Tne  IOC  I-S/A  AX'PE  shall  irpleirient  a  standarc  set  of  interfaces  and 
crctccols  to  coriirunicace  .■.itn  scanaard  suoscrider  terniinals  ana  tne  I.-\S 
net'.vOi'K.  There  snail  oe  'variations  requireu  for  certain  specific  subscriaers 
as  specifiea  herein. 

5  . 1  Svibscriber  Interfaces 

5.1.1  General  Saoscrioer  Terminal  Iriterfaces 

Tne  I-S/A  AMPE  snail  oe  capaole  of  interfacing  to  terminals  '.vhich  conform 
to  the  IAS  physical  ana  link  level  protocols  specifiea  in  paragraphs  4.2.1  and 
4.2.2.  Terminal  speeds  up  to  and  including  9.6  kilobits/sec  shall  be 
supported . 

a. 1.2  Specific  Subscriber  Interfaces 

Tne  interfaces  of  specific  US  and  Alliea  subscribers  are  specifiea  herein. 

5. 1.2.1  US  Subscriber  Interfaces 

5. 1.2. 1.1  ASC  Transitional/I-S/A  Ai^PE  Contingency  Interface 

Tne  I-S/A  AMPE  shall  be  required  to  interface  with  the  AUTOOIN  Switching 
Centers  (ASCs)  to  exchange  message  traffic.  The  I-S/A  AMPE  shall  interface 
with  tne  ASC  using  AUTOOIN  MODE  I  protocols  for  terminals.  During  traffic 
interchange  with  ASCs,  tne  I-S/A  AMPE  will  be  viewed  by  the  AScs  as  an  AUTODIiN 
terminal.  In  like  fashion,  under  contingency  conditions,  two  airectly 
connected  I-S/A  AMPEs  snail  be  able  to  interchange  message  traffic. 

5. 1.2. 1.2  Tactical  Interface 

The  I-S/A  AMPE  shall  be  designed  to  interface  with  the  TRI-TAC  equipment 
in  accordance  with  TRI-TAC  Interface  Control  Document,  ICD-015,  see  2.5h. 

5  . 1 . 2 . 1 . 3  General  Serv i ce^  Ai^m inistrati on  ( GS^  Interface 

The  GSA  Advanced  Record  System  (ARS)  users  shall  interface  to  the  I-S/A 
AMPE  via  DCS  Mode  I,  using  the  JANAP-128  format  with  the  following  exceptions 
(see  Reference  2. 5j . ) ; 

a.  Straggler  detection  is  not  universally  provided  on  messages 
received  from  GSA.  Upon  receipt  of  a  GSA  message  without  an  EOM  validation 
number  (EOWVALhO),  the  I-S/A  AMPE  shall  append  the  correct  EOMVALUO  to  the 
message  so  that  the  message  can  then  be  processed  through  the  AUTODIN  network 
the  same  manner  as  other  messages. 

b.  Suspected  duplicate  messages  received  for  delivery  to  GSA  shall 
have  the  pilot  stripped  by  the  destination  I-S/A  AMPE  prior  to  transmission  to 
GSA. 
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trapisn’issicn  lo  the  suDScriber,  tne  prirarj  ithe  "prire"  is  tue  first 

li'ueo  friemaer;  is  used.  It  it  is  i.oSv,  tiic  seCiia  cnannel  is  selectea.  If  it 
is  Dus;. ,  tiie  tnira,  ena  su  on.  /.nile  t.-ierc  is  no  theoretical  limit  to  tiie 
n.,;o-r  of  cnanr.cls  ’.'.nicii  can  be  lin^ac,  tnc  practical  limit  so  far  as  neec  is 
concernec  is  usually  -r  or  5  r.eirters.  Tnese  cnanr,els  are  cesignatec  for 
reference  purposes  as  A,  B,  C,  etc.  Miien  members  of  a  lin<  use  Transmission 
Icentifier  (TI)  lines,  the  Channel  Identifier  portion  of  the  TI  Line  has  the 
aipnaoetic  oesignator  as  Cne  thirc  character  so  that  if,  for  example,  terminal 
k^XX.\Ln  is  ccnnecteo  to  the  I-S/A  n.fPE  by  three  linxec  channels,  the  "Channel 
Identifier"  .-.ill  oe  nLA,  KLB,  an^.  rvi.C.  nil  link  member  channels  shall  be 
classmarxea  iaentical  so  far  as  communities,  security,  ana  Language  .'"edia 
Format  are  concerned.  Memoers  can  de  of  different  speed  ano  contain 

different  cryptos  and  modems.  This  will  be  a  controlleo  '■apability  offered 
only  to  selected  subscrioers  and  shall  be  unoer  close  control  by  the  I-S/A 


5 . 2  Lat.vcrk  Interface 

The  I-S/A  Ai'iPE  shall  have  a  standard  network  interface  with  the  ImS 
aackdone.  The  IOC  I-S/A  AMPE  stanoaro  interface  to  the  backbone  is  supporteo 
Dy  a  layered  protocol  structure  cescribed  in  paragraph  u.i.  The  standard  link 
protocol  to  the  netwerx  shall  be  in  accoroance  with  paragraph  4.2.2.1.f.  At 
itigiier  levels  the  stanoard  protocols  to  tne  network  shall  be  in  accordance 
with  paragraphs  4.2.3,  4.2.4,  4.2.5  and  4.2.6. 

Strict  aaherence  to  protocol  layering  is  requireo  so  that  (1)  additional 
protocols  can  Pe  aaoeo  at  tne  appropriate  levels  unoer  tne  functional 
mocularity  growth  feature,  and  (2)  existing  protocols  can  be  mooified  ano/or 
replaced  without  mutual  interferences.  The  requirement  for  security  shall  not 
nulliry  the  requirement  for  protocol  layering.  This  constraint  is  necessary 
so  that  Red/Black  separation  can  be  placeo  at  any  desired  level  in  the 
protocol  nierarchy.  If  for  security  reasons  a  protocol  is  separated  into 
secure  and  non-secure  functions,  these  functions  shall  not  be  conibined  with 
functions  of  other  protocols. 

5 . 3  AUTOVON  Interface 

The  contractor  shall  design  the  AUTOVON  interface  to  be  used  for  trunk  and 
subscriber  line  restoral  in  degraded  mode  by  aial-up  and  manual  patch.  The 
parameters  for  the  interface  shall  be  in  accordance  with  OCAC  370-V175-6 
"AUTOVOh  System  Interface  Criteria,  Chapter  XI,  Interface  with  Other 
Systems."  The  contractor  shall  use  available  AUTOVON  station  arrangements  to 
provioe  the  terminal  and  modems  and  data  auxiliary  equipment.  The  speeds  that 
shall  be  accommodated  are: 


75  X  2**n  bitsysec 
n=l,2,3,4,5,6,7 


n 
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6.0  HUMAN  interfaces 


The  purpose  of  human  engineering  design  principles  and  practices  is  to 
acmeve  mission  success  through  integration  of  the  human  factors  into  tne 
system,  subsystem,  equipment,  facility  and  achieve  effectiveness,  simplicity, 
efficiency,  reliability  and  safety  of  system  operation,  training  ano 
maintenance. 

Tne  I-S/A  AMPE  shall  be  designed  to  provide  work  environments  which  foster 
effective  procedures,  work  patterns  and  personnel  satety  ano  health  and  .Aiich 
minimize  discomfort,  distraction  ano  any  other  factors  which  degrade  huiiian 
performance  or  increase  the  probablity  of  error.  A  fail  safe  design  shall  be 
provided  in  those  areas  where  failure  can  disable  the  system  or  cause 
catastrophe  through  damage  to  equipment.  The  I-S/A  AMPE  shall  represent  the 
simplest  design  consistent  with  functional  requirements  and  expected  service 
conditions . 

The  contractor  shall  use  and  comply  with  the  criteria  specified  in 
MIL-STD-1472B,  MIL-P-7788,  MIL-STD-188-1 14,  MIL-STD-195,  MIL-STD-454  and 
MlL-H-4b855 . 

6 . 1  Human  Engineering  Design 

The  design  of  the  I-S/A  AMPE  shall  include  consideration  of  human 
engineering,  life  support,  and  biomedical  factors  that  affect  human 
performance  including,  when  applicable: 

a.  Satisfactory  atmospheric  conditions  including  composition, 
pressure,  temperature  and  humidity,  including  safeguards  against  uncontrolled 
variability  beyond  acceptable  limits. 

b.  Range  of  acoustic  noise,  vibration,  acceleration,  shock,  blast, 
and  impact  forces  ano  safeguards  against  uncontrolled  variability  beyond 
acceptable  limits. 

c.  Protection  from  thermal,  toxicological,  radiological, 
electromagnetic,  pyrotechnic,  visual,  and  other  hazards. 

d.  Adequate  space  for  personnel,  their  equipment,  and  free  volume 
for  the  movements  they  are  required  to  perform  during  operation  and 
maintenance  tasks  under  both  normal  and  emergency  conditions. 

e.  Adequate  physical,  visual,  auditory,  and  other  communication 
links  between  the  personnel,  and  between  personnel  and  their  equipment,  under 
both  normal  and  emergency  conditions. 

f.  Efficient  arrangement  of  operation  and  maintenance  workplaces, 
equipment,  controls,  and  displays. 

g.  Adequate  natural  or  artificial  illumination  for  the  performance 
of  operation,  control,  training,  and  maintenance. 
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h.  Provision  of  non-restr icti ve  personal  life  support  ana  protective 
equipment. 

i.  Provisions  for  minimizing  psychophysiological  stress,  ana  fatigue. 

j.  Design  features  to  assure  rapidity,  safety,  ease  ana  economy  of 
maintenance  in  normal,  aaverse  and  emergency  maintenance  environments. 

Satisfactory  tools. 

l.  Tne  clotning  anc  personal  equipment  (C/PEj  to  oe  worn  oy 
personnel  operating  or  maintaining  the  equipment  shall  be  consiaered  in  the 
aesign  location  and  layout  of  workspace  and  maintenance. 

m.  Information  processing  rates,  decision-making  effectiveness. 

6 . c  Interaction 

Tne  cesign  of  the  I-S/A  AI'lPE  snail  reflect  the  interaction  requirements  of 
crew  servea  equipment.  If  more  than  one  crew  member  must  have  simultaneous 
access  to  a  particular  group  of  controls  or  displays  in  oroer  to  insure  proper 
functioning  of  a  system/subsystem,  the  operator  assigned  to  control  ana 
monitor  a  particular  function  shall  have  physical  and  visual  access  to  all 
controls  and  displays  necessary.  The  interaction  shall  be  in  accordance  witn 
the  aocuments  specified  in  paragraph  6.0. 


6.3  Safety 


The  contractor  shall  give  careful  consideration  to  safety  factors 
including  minimization  of  potential  human  error  in  the  operation  and 
maintenance  of  the  system.  The  contractor  shall  conform  to  the  proceaures 
within  the  aocuments  specified  in  paragraph  6.0. 


6.4  Maintainabi 1 ity 

The  contractor  snail  aesign  the  I-S/A  AMPE  to  incorporate  standard  parts 
to  the  maximum  extent  possible  and  shall  conform  to  the  specifications  within 
the  documents  specified  in  paragraph  6.0. 


6.4.1  Special  Tools 


Special  tools  required  for  adjustment  shall  be  securely  mountea  within  the 
equipment  in  a  readily  accessible  location. 


6.4.2  Modular  Replacement 

The  I-S/A  AXPE  shall  be  designed  ana  constructed  for  replacement  of  small 
electronic  assemblies  by  replacing  modular  packages.  It  shall  oe  designed  in 
a  manner  such  that  rapia  and  easy  removal  and  replacement  can  be  accomplished 
by  one  person  where  structural  and  functional  limitations  permit  within  the 
weight  limitations  contained  in  paragraph  5.9.11.3  of  MIL-ST0-1472B. 
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7.0  SECURITY  CONTEXT 


It  'iiust  be  carefully  noted  that  the  I-S/A  AMPE  has  the  requirerr,ent  to 
siiiiultaneously  hancle  messages  at  varying  levels  of  classification  ana 
compariiiientation .  Tnis  simultaneous  inu Iti -cl assi fi cation ,  multi- 
compartmentaticn  usage  dictates  very  close  attention  to  the  security  aspects 
associated  rtith  the  I-S/A  AMPE  (e.g.,  design,  test,  installation,  etc.) 
Aoequate  security  reliability  (i.e.,  the  required  security  protection  level  is 
maintainable)  can  be  acnieveo  proviaeu  tncre  is  strict  compliance  with  ihe 
following  sec^ritj  requirements. 

7 . 1  Functional  Requirements 

The  I-S/A  AMPE  design  shall  provide  the  following  features: 

7.1.1  Protection  from  Unauthorizea  Disclosure  or  Compromise  of  Information 

This  feature  implements  both  the  nonoi scretionary  (or  mandatory)  and  the 
discretionary  DoD  Security  Policies  in  that  information  will  be  cisclosed  only 
to  users  or  subscribers  who  are  cleared  for  the  information's  level  of 
classification  and  also  possess  the  required  "need  to  know"  certification. 

This  feature  requires  that  all  authorized  users  or  subscribers  be  "well  known" 
to  their  servicing  I-S/A  AMPE  and  be  positively  identified. 

7.1.2  Protection  from  Penial  of  Authorized  Service  to  Authorized  Users  or 
Subscribers 

This  feature  entails  that  information  be  accepted  from,  ana  delivered  to, 
only  authorized  and  specifically  addressed  users  or  subscribers. 

Additionally,  for  certain  categories  or  classes  of  users  or  subscribers, 
authorized  services  are  guaranteed  to  be  available,  assuming  that  the  system 
is  in  fact  operational.  Other  terminology  often  used  for  this  feature  is  that 
the  system  will  be  "non  blocking"  to  certain  categories  of  users  or 
subscribers.  However,  this  feature  obviously  must  comply  with  the 
restrictions  imposed  by  the  protection  from  compromise  feature. 

7.1.3  Protection  from  the  Undetected  Unauthorized  Alteration  of  Information 
Entrusted  to  the  System 

This  feature  insures  the  integrity  of  both  the  system  itself  as  well  as 
the  information  (messages)  transiting  the  system.  Additionally,  this  feature 
complements  and  complies  with  the  restrictions  imposed  by  the  two  features 
previously  discussed. 

7.2  Network  Connection 


For  DON  connectivity,  the  Fault  Isolation  and  Correction  (FI4C)  Capability 
(see  FRD  para  3.3.7)  shall  ensure  that  the  network  connections (s )  are  via  an 
Ena-to-End  Encryption  (E^)  device  and  if  the  network  switching  noce  is  not 
collocated,  that  an  appropriate  link  encryption  device  is  also  on  the  line  and 
operational.  The  FI&C  shall  ensure  that  units  associated  with  the  network 
interconnection  are  properly  synchronized.  For  AUTOOIN  connectivity,  the  FI&C 
shall  ensure  an  appropriate  link  encryption  device  is  online  and  operational 
where  required. 
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SECTION  25  -  MODE  IB  LINK  PROTOCOL 

25.1  INTRODUCTION.  Mode  IB  is  a  character-oriented  synchronous 
type  of  link, control  which  uses  character  parity  and  block  parity 
checking  along  with  retransmission  of  errored  messages  to  achieve 
an  error  detection  and  correction  capability.  AUTODIN  II  will 
operate  with  subscribers  conforming  to  the  Two-Way  Alternate 
Point-to-Point  link  control  procedures  described  in  documents 
referenced  below.  This  mode  is  used  by  subscribers  who  employ 
Binary  Synchronous  Communications  (BSC)  procedures. 

25.2  APPLICABLE  DOCUMENTS 

a.  Binary  Synchronous  Communications,  IBM  Order  No.  GA27- 
3004-2,  dated  October  1970. 

b.  American  National  Standards  Institute  (ANSI)  X3. 28-1971  - 
Procedures  for  the  use  of  Communication  Control  Characters 
of  American  National  Standard  Code  for  Information  Inter¬ 
change  in  Data  Communications  Links,  dated  10  March  1971. 

25.3  MODE  IB  CHARACTERISTICS 


a.  Block-by-block  coordination 

b.  Synchronous  transmission 

c.  Half-duplex  data  transmission  (two-way  alternate) 

d.  Character  parity  and  block  parity  (BCC) 

e.  Transmission  code  8-bit  ASCII  (seven  data  bits  plus  one 
parity  bit) 

f.  Odd  parity  for  all  control  characters  and  data  characters 

g.  Each  block  is  of  variable  length 

h.  Number  of  blocks  per  message  is  variable 

i.  Characters  are  transmitted  serially  bit-by-bit,  with  the 
low  order  bit  first  and  the  parity  bit  last 

j.  A  message  will  consist  of  a  header  block  preceded  with  SOH 
characters  and  ending  with  ETB  and  BCC.  Also,  the  last 
block  begins  with  STX  and  ends  with  ETX  and  BCC. 
Intervening  blocks  begin  with  STX  and  end  with  ETB  and  BCC 

k.  The  character  parity  is  checked  and  generated  by  the  Line 
Termination  Unit  (LTU),  both  at  the  input  and  at  the 
output 

l.  The  status  of  the  check  is  passed  on  to  LCM  software 
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m.  The  block  parity  is  checked  and  generated  by  the  LCM,  and 
the  status  is  made  available  to  TAG  software 

n.  The  status  information  that  will  be  made  available  to  TAG 

software  is:  _  *> 

1.  Loss  of  synchronization 

2.  Gharacter  error 

3.  Block  error 

4.  ETB,  ETX 

5.  Synchronization  established 

6.  Byte  count  equal  to  zero 

o.  LGM  will  not  initiate  recovery  or  acknowledgment  proce¬ 
dures  other  than  inform  TAG  with  the  above-mentioned 
statuses 

p.  All  actions  resulting  from  the  above  statuses  are 
initiated  by  TAG  software 

q.  LGM  will  recognize  and  remove  all  SYNG  characters  from  the 
input  data  stream.  Indication  that  LGM  is  receiving 
synchronization  will  be  available  for  status  reporting. 

25.4  BINARY  SYNGHRONOUS  GOMMUNIGA'^IONS .  Binary  Synchronous  Gom- 
munications  (BSG)  procedure  provides  a  set  of  rules  for  synchro¬ 
nous  transmission  of  binary  coded  data.  All  data  in  BSG  is 
transmitted  as  a  serial  stream  of  binary  digits.  Synchronous 
communications  means  that  the  active  receiving  station  on  a 
communications  channel  operates  in  step  with  the  transmitting 
station  through  the  recognition  of  a  specific  bit  pattern  (sync 
pattern)  at  the  beginning  of  each  transmission. 

25.5  POINT-TO-POINT  OPERATION.  A  point-to-point  data  link  con¬ 
sists  of  a  communications  facility  between  only  two  stations. 

For  point-to-point  operation,  a  contention  situation  exists  whereby 
both  stations  can  attempt  to  use  the  communication  line  simulta¬ 
neously.  To  minimize  this  possibility,  a  station  bids  for  the 
line  using  the  ENQ  control  character.  Refer  to  the  Mode  IB  for¬ 
mats  in  paragraph  25.12.  The  SYNG  SYNG  ENQ  sequence  (SYNG  SYNG 
represents  the  synchronous  idle  characters)  provides  the  means 
for  controlling  the  line.  If  simultaneous  bidding  occurs,  one 
station  must  persist  in  its  bidding  attempt  to  break  the  conten¬ 
tion  condition.  A  station  receiving  this  sequence  (and  ready 
for  message  reception)  replies  with  SYNG  SYNG  AGKO.  If  the 
station  is  not  ready  to  receive,  it  replies  with  either  of  the 
following : 
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a.  SYNC  SYNC  NAK  (negative  acknowledgment) 

b.  SYNC  SYNC  WACK  (wait  before  transmit  positive  acknowl¬ 
edgment)  . 

To  avoid  the  problems  associated  with  simultaneous  transmission 
requests,  each  station  is  assigned  a  priority  -  primary  or  second¬ 
ary.  The  higher  priority  (primary)  station  sends  an  ENQ  to 
acquire  the  idle  line.  It  will  continue  to  do  so  until  it  receives 
an  affirmative  response  or  until  the  retry  limits  of  the  primary 
station  are  reached.  If  the  primary  station  receives  an  ENQ  and 
it  has  not  initiated  a  request  for  the  line,  then  it  replies  with 
ACKO  (if  ready  to  receive),  WACK,  or  NAK.  Thus  the  secondary 
station  can  gain  control  of  the  line  for  a  transmission  only 
when  the  line  is  left  free  by  the  primary  station. 

Message  transmission  is  ended  and  the  line  is  returned  to  an  idle 
state  by  the  transmission  of  SYNC  SYNC  EOT.  The  station  sending 
SYNC  SYNC  EOT  will  not  send  an  initialization  sequence  before  3 
seconds  have  elapsed,  thus  allowing  the  other  station  to  bid  for 
the  line. 

25.6  DATA  LINK  CONTROL  CHARACTERS.  Mode  IB  protocols  control 
data  links  through  the  use  of  the  following  control  characters 
and  sequences; 

a.  SYNC  -  Synchronous  idle 

b.  SOH  -  Start  of  heading 

c.  STX  -  Start  of  text 

d.  ITB  -  End  of  intermediate  transmission  block 

e.  ETB  -  End  of  transmission  block 

f.  ETX  -  End  of  text 

g.  EOT  -  End  of  transmission 

h.  ENQ  -  Enquiry 

i.  ACKO/ACKl  -  Alternate  affirmative  acknowledgment 

j.  NAK  -  Negative  acknowledgment 
h.  DLE  -  Data  link  escape 

l.  RVI  -  Reverse  interrupt 

m.  TTD  -  Temporary  text  delay 

n.  DLE  EOT  -  Disconnect  sequence  for  switched  network. 

The  bit  configuration  of  Mode  13  control  characters  is  shown  in 
Tables  3-IV  and  B-V.  Refer  to  Mode  IB  formats  in  25.12. 

25.6.1  SYNC  -  Synchronous  Idle.  This  character  is  used  to 
establish  and  maintain  synchronization  and  as  a  time  fill  in  the 
absence  of  any  data  or  other  control  character.  Two  contiguous 
sync's  at  the  start  of  each  transmission  (SYNC  SYNC)  are  referred 
to  as  the  character-phase  synchronization  pattern. 
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25.6.2  SOH  -  Start  of  Heading.  This  character  precedes  a  block  of 
heading  characters.  A  heading  consists  of  auxiliary  information 
(such  as  routing  and  priority)  necessary  for  the  system  to  process 
the  text  portion  of  the  message. 

25.6.3  STX  -  Start  of  Text.  This  character  precedes  a  block  of 
text  characters.  Text  is  that  portion  of  a  message  treated  as  an 
entity  to  be  transmitted  through  to  the  ultimate  destination 
without  change. 

25.6.4  ETB  -  End  of  Transmission  Block.  The  ETB  character  indi¬ 
cates  the  ■’nd  of  a  block  of  characters  started  with  SOH  or  STX. 

The  blocking  structure  is  not  necessarily  related  to  the  process¬ 
ing  format.  The  block-check  character  (BCC)  is  sent  immediately 
following  ETB.  ETB  requires  a  reply  indicating  the  receiving 
station's  status  (ACKO,  ACKl,  NAK,  or,  optionally,  WACK  or  RVI). 

25.6.5  ITS  -  End  of  Intermediate  Transmission  Block.  The  ITB 
character  (US  in  USASCII)  is  used  to  divide  a  message  (heading  or 
text)  for  error  checking  purposes  without  causing  a  reversal  of 
transmission  direction.  The  block  check  character  (BCC)  imme¬ 
diately  follows  ITB  and  resets  the  block  check  count.  After  the 
first  intermediate  block,  successive  intermediate  blocks  of 

the  same  type  (heading  or  text)  need  not  be  preceded  by  STX 
or  SOH.  If  one  intermediate  block  is  heading  and  the  next  inter¬ 
mediate  block  is  text,  STX  must  begin  the  text  block. 

Normal  line  turnaround  occurs  after  the  last  intermediate  block, 
which  is  terminated  by  ETB  or  ETX.  When  one  of  these  ending 
characters  is  received,  the  receiving  station  responds  to  the 
entire  transmission.  If  a  block  check  error  is  detected  for  any 
of  the  intermediate  blocks,  a  negative  reply  is  sent  requiring 
transmission  of  all  intermediate  blocks. 

All  BSC  stations  must  have  the  ability  to  receive  ITB  and  its 
attendant  BCC.  The  ability  to  transmit  the  ITB  character  is  a 
station  option. 

25.6.6  ETX  -  End  of  Text.  The  ETX  character  terminates  a  block  of 
characters  started  with  STX  or  SOH  and  transmitted  as  an  entity. 

The  block  check  character  is  sent  immediately  following  ETX.  ETX 
requires  a  reply  indicating  the  receiving  station's  status. 

25.6.7  EOT  -  End  of  Transmission.  This  character  indicates  the 
end  of  a  message  transmission,  which  may  contain  one  or  more  blocks, 
including  text  and  associated  heading.  It  causes  a  reset  of  a 
station  on  the  line.  EOT  is  also  used  as  an  abort  signal  to  indi¬ 
cate  a  system  malfunction  or  operational  situation  that  precludes 
continuation  of  the  message  transmission. 
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25.6.8  ENQ  -  Enquiry.  The  ENQ  character  is  used  to  obtain  a 
repeat  transmission  of  the  response  to  a  message  block  if  the 
original  response  was  garbled  or  was  not  received  when  expected. 

ENQ  is  also  used  to  bid  for  the  lina  when  using..a  point-to-point 
line  connection.  If  the  sender  wishes  to  abort  a  transmission, 
an  ENQ  may  be  inserted  following  text  characters  and  the  block 
is  not  terminated  with  ETS  or  ETX  and  aCC.  The  receiver  will 
discard  the  transmission.  NAK  (Negative  Acknowledgment)  is 

the  reply  to  the  aborted  transmission. 

25.6.9  ACKO/ACKl  -  Affirmative  Acknowledgment.  ACKO  and  ACKl 
are  the  two  character  sequences  DLEO  and  DLSl,  respectively. 

Where  required,  these  replies,  in  proper  sequence,  indicate  that 
the  previous  block  was  accepted  without  error  and  that  the 
receiver  is  ready  to  accept  the  next  blocx  of  the  transmission. 

ACKO  is  the  positive  response  to  line  bid  in  operation.  Mode 

13  alternately  uses  ACKO  and  ACKl  as  affirmative  replies.  The 
use  of  ACKO  and  ACKl  provides  a  sequential  checking  control  for 
a  series  of  replies. 

25.6.10  WACK  -  W'ai t-Bef ore-Transmi t  Positive  Acknowledgment. 

WACK  (OLE;  in  USASCII)  allows  a  receiving  station  to  indicate  a 
temporarily  not  ready  to  receive  condition  to  the  transmitting 
station.  It  can  be  sent  as  a  response  to  a  text  or  heading  block, 

line  bid  (point-to-point  with  contention),  or  an  ID  (identification 

number)  line  bid  sequence  (switched  network).  vVACK  is  a  positive 
acknowledgment  to  the  received  data  block  or  to  selection. 

The  normal  transmitting  station  response  to  WACK  is  ENQ,  but  EOT 
and  DLE  EOT  (switched  network)  are  also  valid  responses.  When  ENQ 
is  received,  the  receiving  station  will  continue  to  respond  with 

WACK  until  it  is  ready  to  continue.  The  ability  to  receive  WACK  ~ 

mandatory  for  all  stations,  but  the  capability  to  send  WACK  is 
optional . 

25.6.11  NAK  -  Negative  Acknowledgment.  NAK  indicates  that  the 
previous  block  was  received  in  error  and  that  the  receiver  is  ready 
to  accept  a  retransmission  of  the  erroneous  block.  It  is  also  the 
not-ready  reoly  to  line  bid.  upon  receipt  of  3  NAKS  for  a  single  line  bloci(  . 
the  higher  leveT  nrotocol  will  be  notified  and  attempts  to  deliver  this  line 
bj.ock  will  concintie. 

25.6.12  DLE  -  Data  Link  Escape.  DLE  is  a  control  character  used 
exclusively  to  provide  supplementary  line  control  characters,  such 
as  WACK  (DLE;)r  ACKO  (DLEO),  ACKl  (DLEl),  and  RVI  (DLE<). 

25.6.13  RVI  -  Reverse  Interrupt.  The  RVI  (DLE<  in  USASCII)  con¬ 
trol  sequence  is  a  positive  response  used  in  place  of  the  ACKO 

or  ACKl  positive  acknowledgment.  RVI  is  transmitted  by  a  receiv¬ 
ing  station  to  request  termination  of  the  current  transmission 
because  of  a  high  priority  message  which  it  must  transmit  to 
the  sending  station.  Successive  RVI's  cannot  be  transmitted, 
except  in  response  to  ENQ.  ^ 
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The  sending  station  treats  the  RVI  as  a  positive  acknowledgment 
and  responds  by  transmitting  all  data  that  prevents  it  from 
becoming  a  receiving  station.  More  than  one  block  transmission 
nay  be  required  to  empty  the  sending  station's  buffers. 

The  ability  to  receive  RVI  is  mandatory  for  all  stations,  but  the 
ability  to  transmit  RVI  is  optional. 

25.6.14  TTD  -  Temporary  Text  Delay.  The  TTD  control  sequence  is 
sent  by  a  sending  station  in  message  transfer  state  when  it  wishes 
to  retain  the  line,  but  is  not  ready  to  transmit.  The  TTD  control 
sequence  (STX  ENQ)  is  normally  sent  after  approximately  2  seconds 
if  the  sending  station  is  not  capable  of  transmitting  the  next 
text  block  or  initial  text  block  within  that  time.  This  2-second 
timeout  avoids  the  nominal  3-second  receive  timeout  at  the 
receiving  station. 

The  receiving  station  responds  NAK  to  the  TTD  sequence  and  waits 
for  transmission  to  begin.  If  the  sending  station  is  still  not 
ready  to  transmit,  the  TTD  sequence  can  be  repeated  one  or  more 
times. 

This  delay  in  transmission  can  occur  when  the  sending  station's 
input  device  has  not  completely  filled  the  buffer  due  to  inherent 
machine  timings.  TTD  is  also  transmitted  by  a  sending  station 
in  message  transfer  mode  to  indicate  to  the  receiver  that  it  is 
aborting  the  current  transmission.  After  receiving  NAK  to  this 
TTD  sequence,  the  sending  station  sends  EOT  resetting  the  stations 
to  control  mode  (forward  abort). 

25.6.15  Disconnect  Sequence  for  a  Switched  Line  -  DLE  EOT.  Trans¬ 
mission  of  DLE  EOT  on  a  switched  line  indicates  to  the  receiver 
that  the  transmitter  is  going  on-hook.  Either  the  calling  or  the 
called  station  may  transmit  this  disconnect  sequence.  DLE  EOT  is 
normally  transmitted  when  all  message  exchanges  are  complete  and 
may  optionally  be  transmitted  at  any  time  instead  of  EOT  to  cause 

a  disconnect. 

25.7  ERROR  CHECKING.  All  characters  received  from  the  terminal 
subscriber  will  be  passed  to  TAG  (except  for  SYNC  characters)  after 
they  are  checked  for  odd  parity  by  the  LCM.  If  a  character  parity 
is  detected,  the  appropriate  status  information  will  be  set,  and 
the  LCM  will  continue  to  accept  characters  until  a  valid  termina¬ 
ting  character  is  received.  On  detection  of  ETX,  ETB ,  or  ITB, 
the  next  succeeding  character  will  be  compared  to  the  locally 
generated  longitudinal  redundancy  check  (LRC),  and  an  error  status 
will  be  generated  if  the  two  do  not  compare. 

In  general,  LRC  is  a  longitudinal  redundancy  check  on  the  total 
data  bits  within  a  block.  An  LRC  is  accumulated  at  both  the 
sending  and  receiving  ends  during  the  transmission  of  a  block. 

This  accumulation  is  called  the  block -check  character  (BCC) , 
and  it  is  transmitted  immediately  following  an  ETB,  ETX,  or  ITB 
character.  The  transmitted  BCC  is  compared  with  the  accumulated 
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BCC  character  at  the  receiving  station  for  an  equal  condition. 

An  equal  comparison  indicates  a  good  transmission  of  the  previous 
block. 

The  LRC  accumulation  is  reset  by  the  first  STX  o:;,SOH  character 
received  after  a  line  turnaround.  In  normal  transmission,  all 
characters  received  after  the  SOH  or  STX  to  the  ETB  or  ETX  includ¬ 
ing  control  characters  are  included  in  the  BCC  accumulation.  Only 
SYNC  characters  are  not  included  in  the  BCC  accumulation.  Follow¬ 
ing  an  ITB  BCC,  the  accumulation  resets  the  block  check  count. 

Refer  to  25.12  for  Mode  IB  data  formats. 

25.8  TIMEOUT  REQUIREMENTS.  Timeouts  are  used  to  prevent  indefi¬ 
nite  data-link  tie-ups  due  to  false  sequences  or  missed  turnaround 
signals  by  providing  a  fixed  time  within  which  any  particular 
operation  must  occur.  Due  to  the  different  requirements  for 
the  various  operations,  four  specific  timeout  functions  are 
provided  as  follows: 

a.  Transmit 

b.  Receive 

c.  Disconnect 

d.  Continue 

The  various  timeout  requirements  of  this  protocol  will  not  be 
performed  by  the  LCM.  These  requirements  will  be  implemented  in 
the  TAC  software. 

25.8.1  Transmit  Timeout.  There  is  a  nominal  1-second  timeout 
that  establishes  the  rate  at  which  synchronizing  idles  are  auto¬ 
matically  inserted  into  transmitted  heading  and  text  data.  In 
normal  data,  the  data  is  being  transmitted  over  the  link  in  a 
normal,  or  nontransparent  mode,  (data  link  control  characters 
are  recognized  as  such  without  being  preceded  by  a  Data  Link 
Escape  (DLE)  character).  Two  consecutive  SYNC-idle  characters 
(SYNC  SYNC)  are  inserted  every  second.  If  business  machine 
clocking  is  used,  DLE  SYNC  insertion  is  required  at  least  every 
84  characters  to  ensure  maintenance  of  bit  synchronization  in 
the  event  of  transitionless  data.  There  must  be  at  least  54 
characters  between  each  DLE  SYNC.  If  there  are  less  than  54 
characters  between  DLE  SYNC  sequences,  the  line  will  lose  its 
link  protocol  synchronization  and  loss  of  data  will  occur. 
SYNC-idles  are  inserted  in  the  message  for  timing  purposes  only, 
and  have  no  effect  on  the  message  format. 

25.8.2  Receive  Timeout.  This  is  a  nominal  3-second  timeout  and  is 
used  as  follows: 

a.  Limits  the  waiting  time  tolerated  for  a  transmitting 
station  to  receive  a  reply. 


‘i 
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b.  Permits  any  receiving  or  monitoring  station  to  check 

the  line  for  SYNC-idle  signals.  These  SYNC-idles  indicate 
that  the  transmission  is  continuing;  thus,  this  timeout 
is  reset  and  restarted  each  time  a  SYNC-idle  is  detected. 

25.8.3  Disconnect  Timeout.  This  timeout  is  used  optionally  on 
switched  network  data  links.  It  is  a  nominal  20-second  timeout 
used  to  prevent  a  station  holding  a  connection  for  prolonged  per¬ 
iods  of  inactivity.  After  20  seconds  of  inactivity,  the  station 
will  disconnect  from  the  switched  network. 

25.8.4  Continue  Timeout.  This  is  a  nominal  2-second  timeout 
associated  with  the  transmission  of  TTD  and  WACK.  The  continue 
timeout  is  used  by  stations  where  the  speed  of  input  devices  (for 
transmitting  stations)  or  output  devices  (for  receiving  stations) 
affect  buffer  availability  and  may  cause  transmission  delays. 

TTD  is  sent  by  the  transmitting  station  up  to  2  seconds  after  re¬ 
ceiving  acknowledgment  of  the  previous  block,  if  the  transmitting 
station  is  not  capable  of  sending  the  next  transmission  block 
before  that  time. 

A  receiving  station  must  transmit  WACK  to  indicate  a  temporarily 
not-ready-to-receive  condition  if  it  is  not  able  to  receive  within 
the  2-second  timeout.  The  purpose  of  the  timeout  interval  is  to 
permit  the  receiving  station  to  send  an  appropriate  affirmative 
reply  immediately  if  it  becomes  appropriate  within  the  interval. 

25.9  LOSS  OF  SYNCHRONIZATION.  Loss  of  synchronization  will  be 
determined  by  the  reception  of  one  8-bit  character  of  all  zeros  or 
all  ones  after  character  framing  has  already  been  established. 

Under  these  two  conditions  the  LCM  will  immediately  return  to  a 
waiting-for-input  condition. 

25.10  STANDARD  CODE .  The  AUTODIN  II  system  design  provides  for 
Mode  13  subscribers  to  use  an  8-bit,  odd  parity  ASCII  code.  The 
ASCII  code  is  shown  in  Table  IV  and  will  have  an  added  eighth  bit 
to  form  odd  parity  on  each  character.  Parity  code  conversion  on 
output  lines  will  be  matched  to  the  ANSI  standard. 


25.11  LINS  CONTROL  MODULE  (LCM)  -  LINE  TERMINATION  UNIT  (LTU) 
REQUIREMENTS .  Mode  13  communication  lines  will  be  terminated 
in  a  synchronous  LTU  which,  in  turn,  will  be  connected  to  an  LCM 
microprocessor.  Mode  13  LTU's  will  terminate  and  control  the 
operation  of  full-duplex,  synchronous  communication  lines  using 
point-to-point  procedures.  Mode  13  utilizes  8-bit  ASCII  with 
seven  bits  used  for  data  plus  one  odd-parity  bit.  Odd  parity 
is  maintained  for  all  data,  control,  and  block  framing  characters. 

The  interface  of  these  communication  lines  is  through  a  time- 
division  multiplexer  (TDM)  which,  in  turn,  interfaces  the  TDMI 
LCM  on  a  bit  serial,  character  multiplexed  data  stream.  A  ninth 
bit  with  each  character  is  exchanged  between  the  TDMI  LCM  and 
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the  TDM  for  providing  TDM  control  and  line  control  over  and  above 
the  Mode  IB  protocol.  This  bit,  when  set  to  a  one,  indicates 
TDM  control  is  contained  in  the  following  eight  bits.  This  bit, 
when  set  to  a  zero,  .indicates  valid  data  or  control  information 
is  buried  within  the  protocol  and  is  to  be  exchanged  between 
the  node  and  the  terminals. 

The  LTD  will  interface  with  the  LCM  via  a  bit  parallel  interface 
and  convert  the  data  to  a  serial  bit  stream  on  output.  The  least 
significant  bit  of  the  data  will  be  serialized  first  and  the  parity 
bit  position  serialized  last.  Incoming  serial  data  will  be  packed 
into  a  byte  or  word  format  prior  to  transfer  to  the  LCM. 

Mode  IB  data  are  formatted  into  blocks  of  variable  length  text 
data,  with  leading  and  trailing  control  characters  framing  this 
text  data.  Refer  to  paragraph  25.12  for  Mode  IB  Data  Formats. 

The  final  character  of  a  block  is  a  BCC,  which  is  used  for  error 
control.  The  first  character  of  a  block  is  a  SOH  or  STX.  Receipt 
and  recognition  of  SOH  or  STX  will  trigger  the  BCC  accumulation 
for  the  block.  The  LTU/LCM  will  recognize  the  leading  and  trailing 
control  characters.  On  input,  recognition  of  the  SOH/STX  will 
start  the  text  data  transmission  to  the  TAC.  Detection  of  ETX 
or  ETB  will  cause  the  BCC  check  to  occur.  The  LCM  will  notify 
the  TAC  of  block  message  completion  by  causing  the  appropriate 
status  and  interrupt  to  be  generated.  On  output,  these  control 
characters  will  cause  the  appropriate  actions  in  the  opposite 
directions. 

The  maintenance  of  data  and  control  character  integrity  requires 
proper  synchronization  between  the  transmitting  and  receiving 
elements  of  the  communication  path  between  the  terminals.  The 
synchronous  channel  card  (SCC)  in  the  TDM  will  maintain  this 
synchronization  in  conjunction  with  commands  from  the  KMC-llB/DMS- 
IIB.  The  transmitter  will  precede  all  blocks  of  data  with  a 
minimum  of  four  consecutive  ASCII  SYNC  characters.  The  receiver 
will  recognize  two  consecutive  SYNC  characters  to  synchronize 
itself.  SYNC  characters  will  not  be  forwarded  to  the  TAC;  however, 
an  indication  that  the  SCC  is  receiving  synchronization  will 
be  available  to  the  LCM  for  status  reporting  purposes.  Synchroniza¬ 
tion  will  also  be  transmitted  during  the  idle  link  state  in 
the  absence  of  data. 

All  Mode  IB  characters  have  odd  parity.  Once  synchronization  has 
been  established,  the  LTU  will  check  and  flag  any  character  re¬ 
ceived  with  even  parity  as  an  error  and  forward  this  condition  to 
the  LCM. 

At  the  end  of  each  transfer  and  upon  request,  a  status  word  will  be 
returned  to  the  TAC  processor.  The  status  word  will  indicate  the 
status  of  the  lines. 
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25.12  MODS  IB  DATA  FORMATS.  Figure  B-4  shows  the  Mode  IB  data 
formats  that  will  be  used  in  AUTODIN  II.  The  following  items  are 
illustrated  in  these  figures; 

I 

a.  Initialization  and  One  Way  Operation 

b.  Control  Character  ENQ  -  Enquiry 

c.  Control  Character  NAK  -  Negative  Acknowledgment 

d.  Control  Character  WACK  -  Wait  Before  Transmit  Positive 
Acknowledgment 

e.  Control  Character  RVI  -  Reverse  Interrupt 

f.  Control  Character  ITB  -  End  of  Intermediate  Transmission 
Block 

g.  Control  Character  TTD  -  Temporary  Text  Delay 

h.  Timeouts 

i.  Half-Duplex  Data  Transmission  (Two  Way  Alternate) 

25.12.1  Heading .  The  heading  is  a  block  of  data  starting  with 
SOH  and  containing  one  or  more  characters  that  may  be  used  for 
message  control,  eg,  message  identification,  routing ,■ priority 
and  security) .  SOH  initiates  the  block-check-character  (BCC) 
accumulation.  The  SOH  is  not  included  in  the  accumulation. 

The  heading  is  ended  with  ETB  followed  by  BCC  as  illustrated 

in  Figure  B-4. 

The  heading  can  be  terminated  prematurely  by  use  of  the  ENQ  (indi¬ 
cating  disregard  the  block)  without  the  ETB  and  BCC.  The  receiver 
will  reply  with  a  NAK  and  the  heading  will  be  retransmitted.  This 
is  illustrated  in  Figure  B-4C. ,  Control  Character  NAK  -  Negative 
Acknowledgment. 

The  Mode  IB  heading  data  is  in  accordance  with  the  THP  command 
procedures  described  in  Section  27. 

25.12.2  Text .  The  text  data  is  the  most  significant  portion  of 
the  transmission.  It  is  transmitted  in  complete  units  called 
messages,  which  are  initiated  by  STX  and  concluded  with  ETX. 

Each  message  is  a  complete  unit  that  can  stand  alone  and  is  not 
necessarily  directly  related  to  other  messages  being  transmitted. 

A  message  can  be  subdivided  into  smaller  blocks  for  ease  in 
processing  and  more  efficient  error  control.  Each  block  starts 
with  STX  and  ends  with  ETB  (except  for  the  last  block  of  a  message, 
which  ends  with  ETX).  A  single  transmission  can  contain  any 
number  of  blocks  (ending  with  ETB)  or  messages  (ending  with  ETX). 

An  EOT  following  the  last  ETX  block  indicates  a  normal  end  of 
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transmission.  Message  blocking  without  line  turnaround  can  be 
accomplished  by  using  ITB  (see  paragraph  25.6.5  and  Figure  B-4F, 
Control  Character  ITB  -  End  of  Intermediate  Transmission  Block). 

Control  characters  or  sequences  within  a  block  of.,text  are  not 
allowed.  Any  station  receiving  a  control  character  within  a  text 
block  treats  the  control  character  or  sequence  as  data  and  waits 
for  the  block  check  character  (BCC)  to  detect  a  possible  error.  If 
an  error  is  detected,  normal  recovery  procedures  are  used.  If  no 
error  is  detected,  the  transmission  is  treated  as  valid  data. 

A  block  of  text  data  can  be  terminated  prematurely  by  using  an  ENQ 
character,  which  signals  the  receiver  to  '"disregard  this  block". 

NAK  is  always  the  reply  in  this  situation,  since  the  block  ended 
with  a  forced  error  condition.  An  example  is  shown  in  Figure  B-4C, 
Control  Character  NAK  -  Negative  Acknowledgment. 

25.13  SWITCHED-NETWORK  (DIALUP)  OPERATION.  -  For  switched-network 
operation,  the  point-to-point  connection  can  be  established  by 
either  manual  or  aucoraatic  means.  At  the  PSN  the  call  will  be 
answered  automatically  by  TCMS .  Dialed  connections  are  operated 
as  point-to-point  lines  with  contention.  Both  stations  start  in 
the  "circuit-assurance  mode".  Once  circuit  assurance  is  estab¬ 
lished  and  identified,  the  stations  use  the  normal  BCS  procedures 
required  for  operation  (switched  point-to-point).  When  both 
stations  have  completed  their  message  transmissions,  a  disconnect 
signal  is  normally  sent. 

The  "circuit-assurance  mode"  is  entered  when  the  called  station 
goes  "off-hook".  At  this  time  the  calling  station  is  notified  by 
a  signal  from  its  data  set  that  a  connection  with  another  data  set 
has  been  established.  Once  this  indication  is  received,  the 
calling  station  sends  either  of  the  following  messages: 

WRU  -  Who  are  you  (the  transmitted  sequence  is  S'ifNC  SYNC 

ENQ).  This  requests  the  called  terminal  to  identify 
i tself . 

lAM/WRU  -  (the  transmitted  sequence  is  SYNC  SYNC  (ID)  ENQ 

where  ID  *  station  identification  sequence).  This 
message  identifies  the  calling  station  and  requests 
the  called  station  to  identify  itself. 

Either  message  is  then  followed  by  an  identification  message  from 
the  called  station  as  follows; 

ID  ACKO  -  (the  transmitted  sequence  is  SYNC  SYNC  (ID)  ACKO , 
where  ID  is  optional). 

NOTE 

If  the  received  ID  sequence  is  unsatis¬ 
factory,  then  either  station  can  initiate 
a  disconnect  sequence. 

/J  ■. 
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Additional  signals  available  as  a  reply  to  the  WRU  or  the  lAM/WRU 
message  are: 

NAK  -  This  indicates  that  a  "not  ready"  condition  exists 
at  the  called  station. 

w 

WACK  -  (optional)  This  indicates  that  "temporary  not  ready 
to  continue"  condition  exists  at  the  called  station. 

Refer  to  Figure  B-5  for  Mode  IB  Switched  -  Network  Dialup  Operation. 

All  stations  must  provide  the  capability  to  transmit  identification 
sequences  in  order  to  permit  several  stations  to  operate  on  the 
same  switched  line.  An  identification  (ID)  sequence  can  be  from  2 
to  15  characters  long.  The  minimum  2-character  sequence  consists 
of  the  same  character  transmitted  twice. 

ID  sequences  may  precede  ENQ,  ACKl,  ACKO ,  and  NAK  in  the  control 
mode.  A  receiving  station  must  be  able  to  recognize  the-  above 
control  characters  when  preceded  by  an  ID  sequence.  WACK  must  not 
be  preceded  by  an  ID  sequence. 

Both  stations  exit  from  the  circuit-assurance  mode  following 
satisfactory  initialization  when  any  of  the  following  sequences  are 
sent  or  received: 

a.  SYNC  SYNC  EOT  -  Returns  the  data  link  to  normal  operation, 
control  mode 

b.  SYNC  SYNC  SOH  -  Initiates  a  block  of  header  data 

c.  SYNC  SYNC  STX  -  Initiates  a  block  of  text  data 

All  signals  other  than  those  just  described  are  considered  to  be 
errors.  If  a  valid  reply  is  not  received  by  the  calling  station 
(following  either  a  WRU  or  an  lAM/WRU)  within  the  receive  timeout 
period,  the  request  message  can  be  retransmitted.  However,  the 
data  link  continues  in  the  circuit-assurance  mode  until  the 
circuit-assurance  sequence  is  satisfactorily  completed. 

The  call  between  stations  can  be  terminated  by  the  disconnect 
timeout  or  by  transmission  of  the  disconnect  sequence:  SYNC  SYNC 
DLE  EOT.  This  sequence  may  be  initiated  by  either  station  when 
operating  on  a  switched-network  basis.  When  operating  with  a 
control  station,  the  control  station  normally  initiates  the  dis¬ 
connect  sequence.  As  this  sequence  is  transmitted  and  received, 
each  station  returns  to  an  on-hook  condition  and  the  line  is 
dropped . 

Although  the  switched  network  (dialup)  operation  is  supported,  the 
dialout  is  not  permitted. 


// 
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Figure  B-4 .  Mode  IB  Link  Protocols 
(Sheet  1  of  11) 
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Figure  B-4.  Mode  IB  Link  Protocols 
(Sheet  4  of  11) 
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i .  ^  ^eGu•  l"9■",e^^s  ■ 

1.1  General  .  T.n's  sect'cn  esiabl  •  s'^es  the  req ji  re'~ents  for  an  I/SA  AXPE  to 
i"ter*ace  w'tn  '■‘cc'j'ar  tt-'yE  A9~ote  Terminal  (VART)  and  to  provide  LINE 
signaling  sjoervi s'cn ,  cata  excnange.  arc  message  processing  in  accordance 
w'tn  f'e  app'i'cab’e  System  Des'gn. 


. . . .  1  I 


he  A''''E  wi '  ■  orov'ce  ALTGGIN  VCGE  I  line  s'cnallnq 


anc  sjperv,  STcn 


1.2  '•‘essage  excnange  between  che  t'-'-E  a^d  '^ART  w-'ll  be  correlated  to  a 
v,"lqoe  select  (SE-)  c'-a'-acte^'  maf^lx  for  eacr.  ’■‘ART.  Th's  matrix  wi  1  '  cross 
''e*e’"e''ce .  oy  te*'m''na1  ID,  tne  2CAC  372-D175-1  SEl  cha'"acters  with  assigned 
VART  unique  SEl  cha'^acters  (ANNEX  2).  Alterations  to  this  matrix  will  be 
.made  by  an  cn-l'ne  table  change,  addressable  by  te'"minal  ID.  Pending  AMPE 
transmit  to  a  MART,  the  AiMPE  will  interrogate  the  received  SEL  character  and 
substitute  an  appropriate  MART  SEL  character  from  the  matrix.  During  AMPE 
"eceive  from  a  MART,  the  AMPE  will  interrogate  the  device  SEL  character  and 
substitute  a'’  approoriate  DCAC  37C-Di75-1  character  f-om  the  matrix.  Select 
character  matrices  shall  delineate  u^'ique  '’'ardvta''e  configurations  for  each 
term,! nal  . 

1.2.1  Messages  transmitted  to  the  MART,  other  than  system  control  messages 
and  Local  Circuit  Switch  ('i-CS)  mcce  traffic,  will  be  in  JAN'AP  12S  format. 

The  MART  will  not  Interpret  the  cMF  code  of  received  messages. 

1.2.2  All  AM’^E^  generated  service  messages  will  be  in  plain  English  text  to 
oe'^mit  non-communication  t-ained  personnel  to  clearly  understand  action 
'"equi  red . 

1.2.3  All  A'^'PE  cere-ated  system,  control  messaces  will  be  formatted  lAW  ANNEX 

1.  ’ 

1.3  '■'essage  -eceived  from  the  MART  may  be  of  three  formats:  JAN'AP  12S,  DD 
173,  and  System  Cont-ol .  Ccmolete  heade-  validation  is  reouired  in  all 
instances  except  when  in  LCS  mode. 

1.3.1  The  format  will  be  identif'ed  by  a  unique  encoded  MART  transmit  SEu 
character . 

1.3.2  DD  173  requires  formatting  to  JANAP  128,  PLA  to  RI  conversion,  local 
distribution,  pacing  and  (when  applicable)  sectioning. 

1.3.3  Comeback  copies  and/or  receipt  of  transmission  are  required. 

1.3. A  The  AMPE  will  accept  and  respond  to  a  MART  generated  RM  control 
characters  lAW  DCAC  37C-D175-1. 

l.A  Limitations  of  the  MART. 


l.A.l  LMF  will  not  be  interpreted  in  determining  device  se'ection. 
1.5  Detailed  Recu' -eme-'ts . 


2 


I'',te'"*ace .  The  AXPE  shall  provide  interface  to  tne  ,VART  in  accordance 
v^'th  f'e  fol'ow'ng  provisions: 

1.5. 1.1  L''.  ne  Control.  Cor-.Lin '  cat' ons  line  control  ^^ill  ce  ir  accordance 

w'tn  TCAC  57C-5175-1,  with  the  -'ollcw'ng  exceptions: 


,napter  /,  aii  rg-gv-erces 


:e  coerat' ons . 


b.  All 


-erences  to  nSc  coeraficna,  q- - qp  _ 


c.  References  to  AUTCVON  tert.ina'';  procedures. 

d.  Chapter  5,  paragraph  7,  reference  to  "difference  between  tne 
tributary  and  ASC  procedures." 

1.5. 1.1.1  Line  contro"  shall  cons' st  of  A'JTCC'iN  “^ode  I,  b' cck-by-bl  cck  and 
continuous.  Continuous  will  be  used  on  n-gh  volume  circuits.  Line  code  will 
ce  in  American  Standard  Code  for  Information  Intercnange  (ASCII). 

're  communications  link  (AXPE  to  MART)  wi'l  consist  of  the  foT-owing:  full 
cue’ ex,  four  wire,  synchronous,  ded’cated  circuits.  Line  soeeds  are  f-'xed  at 
e-'ther  300  B=S,  600  BPS,  1200  5PS,  2<:C0  EPS,  asoO  EPS,  9600  EPS,  or  19. 2K  BPS. 

1.5. 1.2  AVPE  Resoonse  to  .'^ART  R*^. 


1.5. 1.2.1  A  XART  shar'  have  the  caoability  to  generate  and  transmit  RM 
sequences.  RM  sequences  will  normally  be  initiated  by  the  VART  operator  cue 
to  nonavailable  MART  output  dev'Lce(s). 

1.5. 1.2. 2  Upon  receipt  of  each  RM,  from  the  '^ART,  the  AM, PE  will  rgseond  w'th 
a  "CAN"  control  character  sequence  lAW  Chapter  3,  oaragraph  -b,  OCAC 
370-D175-1.  The  AMPE  will  make  one  attempt  to  retransmit  the  rejected 
message.  If  two  consecutive  RM's  are  received  for  the  rejected  message,  the 
AMPE  shall  automatically  respond  by  routing  the  message  to  intercept  (by  MART 
SEL  Char  anc  termina’:  ID). 

1.5. 1.2. 2.1  AMPE  shall  respond  to  an  RM  lAW  para  1.5. 1.2.2  above  and  by 
providing  and  advisory  message  to  the  AMPE  system  console.  This  advisory 
will  include  as  a  minimum  the  following  information: 

a.  Terminal  identifier/3  positions. 

b.  Select  character/output  device/1  position. 

c.  System  time/A  to  7  positions. 

d.  PAN  number/A  positions. 

e.  Precedence  of  message/l  position. 

f.  LM,F/2  positions. 
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'#1 
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•< 


; .  oi 


’re  N.ART  ray  advise  i-'e  AVPE  ccrsc'e  cDe'-ai 


cev'ce  -a  I  r  CP  v' a  a  sysce' 
' ce’"cect. i a'tpccte  cv  SE_EC' 
ra’ ■--''ci' O'- ■  pg  c-tcv.c  cevices. 


"C'Ci  ressace. 

^  C  -  -  ~a  i;  ^ 


CP  a  cjc; 

~y^z  rtil'i  crc.'ce  *o' 
a'f'c  adc-essec  cc 


1.5. 1.3 


Re''"'cia’ 


'  2  » 


iV'CC 


w  s  p.  a 


a 


"e '  - i  c  1  a'l  1  caci  CP  cf  ■ 
:ce''ac'cps  ■  p,  EC  AC  3' 


as  scecifiec  fc; 


:C9  : 


a.utcratec  'cca1  c'pcl'C  sw'tcp'pg 
c’ -cui  c-tc-c' '"cui  t  link  witP  apct-'e: 


(_CS)  Vcde.  A'^-E  «-il  provide  a  f-ily 


ci'iity  wpe-eip  one  .^'ART  ray  estabi'sh  a 
r  '^AR"  ^avipc  c.de  same  host  A.yPE. 


R  1  i  T 


Requesting  LCS  “^cae.  "he  VAST  w' "  i  req-est  the  circuit  switch 


cc"^necf  cn  to  a  soeci*-'c  te’^'^'ra 
the  A'-'^E.  (See  iNRE.X  1) 


va  a  syste 


trcl  message  t'^arsm’tted  to 


-.5.1.d.2  AVPE  Acceptance  c*  ^CS  Rec^est.  Tne  -'■'-E  wi  1 '  ''cti*y  the 
co’'cer''eG  VAST  of  the  valicatec  rec^est  and  ccp^ection  v'a  a  system,  control 


message.  (See  ANNEX  1) 


The  A‘’'"E  w'll  notify  the 


1.5.1. -.3  AvtE  Rejecticp.  cf  -CS  Recuest, 
c''ici'’atipc  VA.RT  c*  the  rejectee  '■ecuest  v'a  system  cc'trcl  messace 
-NN'EX  1)  ' 


(See 


1 . 5 . 1 .  A  .  4  L'p.e  P-ctccol  .  SEL  cha’'acter  "Y"  wiV  be  inse’'tec  in  t‘'e  second 
*>"aming  position  cf  eac^  line  blocK  transm'tceo  'r,  LCS  mede.  An  excecfion  •  s 
the  system  contp'cl  message  recuesting  di  sccnnect'cn .  In  this  case,  SEL 
character  "V"  is  used. 


LuS  mcce 
e  to  the  AVPE 
e  Aype  uccn 


-ay  rec,.est 
(See  ANNEX 
ece'ot  of  a 


1.5. 1.4. 5  "ermination  of  LCS  Vcde.  Either  ter-'-al 
te’-minaticn  by  transmitting  a  system  confol  "'essag 
1).  Termination  of  LCS  mode  may  be  initiated  by  tr 
~'ash  or  ECP  message  for  either  merm-nal. 

1.5. 1.4. 5.1  High  Prececence  Pre-emption.  Ucon  AVPE  '-eceipt  of  a  "lasn  or 
ECP  message  that  is  destined  for  one  of  two  LCS  connected  terminals,  the  AvpE 
will  terminate  the  LCS  connection  and  transmit  tne  nigh  prececence  -essace  to 
the  appropriate  terminal. 

1.5. 1.4. 5. 2  The  AVPE  will  notify  the  concerned  "^ARTS  of  terminated  LCS  mode 
via  a  system  control  message.  (See  ANNEX  1) 

1.5. 1.4. 5. 3  When  the  LCS  disconnect  is  made  eithe'"  by  .AVPE  ore-emption, 
terminal  request  or  loss  of  c'>cuit  continuity,  the  LCS  ccnnect  procec^re 
~ust  again  be  initiated  at  the  te-mina' 


-  -V  »  -  — - -  p-  — 

furthe'"  L.CS  ope'-aticn  is  '■ecu' red 


.5  AVPE  Receive. 


1.6.1  ‘■'essage  format  types.  A  variety  o*  fc-^ats  a'- 
V.ART  to  the  AVPE.  Specifically,  formats  DD  173,  JANA 
Conf-ol  message,  are  generated  by  tne  ‘■'ART.  Tre 


e  t-apsm' tted  *rcm  the 
?  12S  and  Systems 
at  of  eacp  -essage 


transmitted  ■ s  identif'ed  by  a  un’oue  encoded  VAR’  transmit  SEL  cna-acter. 
deta' . 


Ao*?,-;'(ed  discussion  of  SEL  characters  is  provided  in  ANNEX  2. 

A 


1'3  'or-a^tec  -essaces  are  orepa’^ec  at  tr.e  ‘-'ART  VGU  o'"  CSU.  T''.e 

.t.Cow  w  v  ■*,  itwX  w. 


1.5.1  '‘‘essace  "ec’a.  .A  ■, a'^iaty 


ire  t-ar s,~' t: 


t 


■essace 


■e  jr-c-e  -^n-vt  trars-'t  it;.  c-a’"ac*.e’"s  's  cc-'-e  atec  to  ~essace 
'AA'  rer't-e'"3'  cev'ces  a^c  -“F.  A‘,‘,£X  2  r-cv'ces  c:  sc  jss"c.’'i 


t''a''ST't  ’^ec..’’^e"'0'~ts. 
ic  t^e  sta''ca''c  rerots  te' — ■■'a'' 


L.""Cue  y 


systems  cc 


=  _A  .  -.S  .a  aSsaCa  IC 

!A‘,a-  ’;£  'c  —  at.  are  except' c.r  of  a 

■essace.  (See  A'.NEX  1) 


w’rcj",  t  iect'"ty  ^eve  V'a  idafon.  .*x  ccnpar'scn  c*  tre  c'rccit 
sec-'-'ty  'evel  rt't'-  tessace  class' ‘'cat'cr  -iust  Pe  acco-p' i  seed  by  t.-e  A.V^E. 
2e''ve''y  o*’  "lessaces  witr  c' assl  *' cat'or  '"r  excess  o*  t"e  accressed  c''"'ci.''it 
w' ' '  -ct  be  a' ' Owed. 

1.^.2  "''cn  2recece'',ce  "re-etrt'or.  AX.^E  w'll  crcv'ce  fc-  h'ch  prececence 

b'-e-e-ct' or  c:  Icwe*-  pricr'ty  .Tessaces  ir  acccrcarce  w'tr  JA.N'AP  12S. 

l.’.S  I^-Serv'lce  '^essace  Obficra’  Feature.  The  -V^E  s^a”  aetcrat' cal ''y 
t''a.''s~it  a  blain  text  JAN.AA  123  service  message  to  a  YART  s-bsecce.ct  tc 
c'''c...it  ' t' a""  ■  cat' or  arc  •i.'rr.ec:  ate' y  follow'-rc  the  ^r-se-v'ce  cc^Tiand 
execut'c.r.  Th's  "essace  wfll  advise  tre  ter"ina'  that  tre  c'’rc'j't  'Is  rev  i 
ss^v"*C6  w'tn  Ay  PE. 

1.7. A  Ccrebach  Coo’es  Gata  Yessace  Ac^rcwlecgenert .  Tre  AYFE  will  provide 
■cc"ebacx  copies  for  rarrative  ressaces  trarsciitted  fror  tre  '•'ART.  The 
decision  tc  trarsrr,it  a  ccr.eoach  cocy  shall  be  based  ocon  tre  SEi.  CHAR  arc  "ay 
be  dif-'erent  for  eacr  VART. 

1.7.5  System  Control  '•'essages,  AM?£  shall  ’■ecceribe  a-'C  '•espond  to  systems 
control  messages.  These  messages  are  designed  tc  prov’ce  a  means  of 
reCwest'rc  AYPE  action  ana  for  tre  conveyance  of  i rfe^mation .  The  systems 
control  message  will  be  resf^'ctec  *cr  jse  w'trir  ve  A'-'^E  network  arc  for 
exc.range,  between  AYPE  and  ‘•'ART,  but  not  between  MARTS.  System  control 
messages  are  uniquely  formatted  lAW  ANNEX  1. 

1.7. 5.1  Systems  control  message  will  be  originated  by  A'^'PE  or  MART  as 
•"ecui  red . 


1.7. 5. 2  These  messages  will  be  identified  by  select  character  "V"  present  in 
t^'e  second  framing  cha-'acter  position  of  the  line  block.  The  select  character 
bit  ccn^'curation  found  in  data  blocks  originated  by  the  MARTS  is  unicue  in 
trat  tre  first  five  bits  'certify  the  select  character  and  bits  5  and  7 
identify  the  format  o*  the  "essage  being  transmitted.  AM^E  will  interp'^et 
the  ‘i-'st  *ive  b'lts  o'  the  cha’"acter  present  in  the  second  framing  pcsit'on 
0*  t"e  ''>e  block,  i^  that  cha-acter  is  an  ASCII  "V  "jthe  rem.a''ninc  two  b’'ts 
s'"al’  be  ■•grored.  Upon  receipt  of  systems  ccnt’'cl  messages,  .AMPE  shall  shift 


the  -•■gh: 


aces  and  insert  tre  tnree  letter 


o^’cirating  MART  routing  ind'Icatcr  and  a  space.  The  routing  indicators  will 


be  exf'acted  from  tne  A'^' 


tab  1  e . 


c= te:crv 
'•escc'"  se 


'SC  i 


ccrtrci  "essages  s^a  'an  ’’'tc  w«c  catego'^ies.  "e  *'rst 
cc^a'^s  t^csa  ’^^siar*, s  ccnt''c';  "'assaca^  ar  autc^aw  C 

t'^c"  IPS  -'’'^E.  ~"s  sacc'c  cat.2ca''y  cova''s  t^cse  ~assacss  ''sc'j'r'."g 

•  or .  ~r.e  seccrc  t,ge  's  tre  A'-'PE  z),izeT.s' 

to  c'':o'>ate  o'’C  t''aos~'t  acv  •  so'"' es  to  tos  '■'ARTS.  rc'"~ats  a'"e 
r.  A‘,‘,EX 


- . 


•1 


iyste~s 

-  Q  r  r  -*  * 


■■essaces  -at-'-mc  a^t 


f-o: 


esoo'^oec  tt 


■at'c  rasooose 

0^  oct"*aoG  'a  c  attr^*'  pos't'cts  o  tt^'c..gri  /  *^tat  ate 

_ _ _ _  oy  A'-'AE.  Gocn  -eceipt  cf  task  recoest  a-'c!  o-  cor.p'etior  of 

tas<,  AVAE  will  provide  an  advisory  fcrrr,atted  lAW  existing  protocol  to  the 
ASAE  syste-  console  cf  action  taken  or  to  oe  taken. 

2. 7. 5. 3. 2  Syste)7s  control  messages  or-gi  rated  at  the  X.ART  for  the  pjrpcse  of 
'■"-'o' — afion  and  ■"ooted  by  cc7”a’'d  field  e''try  "NAR"  and  "SVC"  ■’’n  *o’ — ^at 

ositiens  5  tnreogh  7,  On  inpet  AX?E  snail  concurrently  ■"Cute 
:  t-e  A'-'PE  syster  console  VDU  arc  systems  console 
•essages  wh-'ch  exceed  3  li'^.es  in  length  shal'  ce*ault 
to  t^e  AVPE  service  pcs'tion.  "SVC"  coticn  messages  shall  be  routed  to  the 
AMPE  service  position  in  all  cases. 

1.7. 5. 3. 3  A.‘*'“E  operators  shaT,  c!"'g-'nate  syste-s  control  messages  frc7  tne 
systems  console. 

l.~.5.3.A  MART  ge^’erated  systems  control  messages  will  be  restricted  in 
length  to  1,923  characters  or  a  ful'  screen,  v.hen  the  X.ART  generated  systems 
control  message  is  rejected  on  input  fo>"  i  1 1  egal/i  nval  id  ‘orTats,  a  canned 
plain  ■'anguage  service  message  sceci'ying  reason  *or  -ejection  will  be 


C"c‘"5C*6' 

"‘lAR"  cotion  messages 
p-inter.  "NAR"  optior 


generated  and  transmitted  to  the  originating  term-lna 


5  1 


1.7. 5. A  Systems  control  messages  will  not  be  accountable  nor  are  t-ey  to  be 
induced  in  systems  statistics. 

1.7.5  Plain  Language  Service  ‘■'essages.  AMPE  will  create  plain  language 
serv'ce  messages  fo-matted  lAW  JASA?  128  aporeviatec  pla'ncress  fc-  use 
witnin  the  A'^'PE  system.  Service  messages  exenanged  with  the  XAR"  will  be 
identifiable  by  a  unique  SEL  character  (U).  SEL  character  (U)  will  be  placed 
in  the  approor' ate  SEL  character  framing  position. 

1  7.7  meader/EC'^'  Validation.  Header  and  trailer  validation  of  field  entries 
(to  preclude  ASC  rejection)  will  be  accomplished  by  AHPE  prior  to  format 
conversion.  Canned  plain  language  service  messages  reflecting  the 
c' assi  f  i  caf’ on  and  precedence  of  the  refei-enced  message  shall  be  transmitted 
to  the  originating  terminal  citing  i  1 1  egal /i  nval  id  field  entr-fes.  Celivery 
esoonsibi 1 i ty  for  rejected  message  t-affic  shall  lie  wi tn  the  originating 
AVPE  will  RN*  the  XART  uoon  -eceipt  of  invalid  security  at  f'~e  of 


input  a'^d  t-ansmit  a  canned  p^ain,  language  service  message  citing  the  reason 
for  rejection  to  the  '■■'.ART 

1.7.S  SEL  Character  '-'atrix.  AMPE  will  o-evide  a  un'cue  SEL  cha-acter  -atrix 
to  interface  with  each  '■i.ART.  This  matrix  will  be  utilized  tor  SEL  character 
co-ve-sion  on  incoming  message  select  cnaracters  to  tne  unique  cev'ce  SE_ 


c"a’"3c^er 


•E  sra'l 


’"eaa''-'ec  ny  f'e 
rev'ew  f'e  fc^'Crt''' 
se'act  a-a'^aa-.e'"  *a 


cr  arccess'r^g  of  the  '"eae'ved  ressage  tra*fic. 
*ie'cs  in  crcer  tc  asae’^ta'”  toe  acrreat 


e . 


.a-a-age  ‘■‘eaia  at  (_'•'  =  ). 

va'o'**** 

Cartent  Ind’aatc''  Code. 


Select  cha-acte''  conversion  of  AMPE  bound  VAST  input  shai'i  recuire 

eccp'^i cu'^ati on  to  a 
a^'acter  “atr'x  shaM  be 


/ .  b. 


M  d  7 

of 

t'-.e 

select  character  an 

d 

Uv  «  » 

se 

ana'^acte'".  Select 

c"a 

ne-" 

as 

to  a'‘’ow  *0''  *uture 

e  n  n 

cte’- 

ma 

tr  i  X 

shall  ioe  a'terable 

vi  a 

cc~~and  while  syster.  is  on-line. 

1.7.S.3  The  fc'r'cwinc  table  csronstrates  t"e  co-'-el  aticn  between  DCA  and 
'■‘ART  un-'aue  select  cnaracte’'S. 

(*  asierisK  denotes  t.ncse  select  cna'^acters  '^ecuininc  conversion) 


CCA 

SEu  CHAR 

VART 

SEL  CHAR 

V.AR  1  TRAMSV.i  1  ,u 

.AvpE 

A 

A 

5  i-EVE^  Baudot 

D 

c 

card.  hcl'*erith 

(JANAP  128) 

H 

H 

narrat've  (CSU, 

VDU,  S  level 

pape"  taoe)  (JAN 

AP  12S) 

A  or  H 

*U 

Se'-v  i  ce 

- 

V  . 

Systems  control 

message 

- 

Y 

Local  c:''"cuit  sw 

tching 

VART  RECEIVE  FRC*^  AVPE 

A 

t 

M 

5  level,  Baudot 

D 

0 

card,  holle-ith  (JANAP  123 

(ASCII) 

VART  TRANSMIT 

TO  .AVPE 

c 

Card,  flash  (. 

JANAP  123) 

’S 

G 

B  level  ASCII 

,  *lash 

H 

u 

S  leve'  ASCII 
123) 

,  narrat've  (JANA? 

S 

s 

5  level  Baudo 

t,  *lash 

'H 

T 

3  leve’  ASCII 

priority 


7 


A3 


.  .0.-  ,  r,5  'c  icw'^c  C9~crs*v''a^es  tne  ■"e  i  at’ c''S'"  p  cr  :.w,-  c  a 

„'''G-ie  se'.ecG  c''3'-acGe’"S  r  a  '.yp’ca'  XAST  ''a'-'-at've  cc'' f  ■  g^rat  i  on  .  “Message 
'C''’".at  fields  ccnta"' '^g  '  rfor-.ati on  '-ecessary  oc  ocr'-eco  ore  se'ect 
c"a''acte’"  conv9''S'’or  a-^e  iceno'r'ied  Grce-^  cclo'nn  head‘’'''g  "'ields".  As  a 
mnirr.jT. ,  one  or  more  of  the  following  fielcs  r^st  be  inte'-rogatec  by  ^A'PE  to 
accomplish  select  c^a’^acter  convers'on. 


;ct  ^.naracter 


0.  -a^guage  r.ec'a  romat 


c.  Precedence 


G.  v,ontant  inc’catcr  i,cce 


.nd’ cater 


C  lass'  t'cat'.on 


MAUI  l.iiio  OiiLpnl  to  AHIT 


I  f  ;uisni  i  I  ti.'d  in  ICS  mode.-.  In  all  other  instances  c  I  n  ss  i  I' i  (;a  t  i  on  assiijncd  will  In;  corniriinisn  r  n  tc  with  si.-ciirity  l(;v(;l  ol'  i  nl  O  i  iri;i  t  i  on 


roll!  the  AMI>(  ni<;ss.'i<|(:  entry  por.  itinn. 


'  L  ■  U'  •  V  ■  U  ■  I  ' 


'M 

►,  *• 


K 


4 


K-i'. 


I-:’: 

.•r-* 


* 

V 


V*.  -' 
••• 


ASNtX  2 

SELECT  (SEL)  CHARACTERS 

A  '’‘AR~  AV-E  SEL  character  cortains  three  elerents: 
A.  Device  Character 
3.  Fo'^mat  Identification  Code 
C.  Even  -aritv  Bit 


(bits  1-5) 
(bits  6,  7) 
(bit  8) 


2.  Device  Character  Determination.  The  peripheral  device  which  inputs  the 
"essage  text  will  define  the  proper  device  character  to  use  for  message 
transmitted  by  the  ^ART.  Minimal  parameters  for  the  mstriY  are;  DC.AC 
370-3175-1  SEL  CHAR,  RCV  LMF,  Precedence,  Content  Indicator  Code  routing  and 
authorized  Receive  Device  Character. 


^ART  TRANSMIT  DEVICE  CHARACTER 


lode 


(bits  1-5)  of  the 
following  ASCII  characte'"s) : 


A 

3 


U 

V 


MART  RECEIVE  DEVICE  CHARACTER 


Devi ce 


5  LEVEL  PAPER  TAPE  (MART  CONVERTS 
ITA2  to  ASCII) 

RESERVED 

3  TRACK  MAG  TAPE  RESERVED 
CARD  HOLLERITH 
RESERVED 

NARRATIVE  (OSU,  VDU,  AND  8  LEVEL 
PAPER  TAPE) 

SERVICE  MESSAGE 

SYSTEM  CONTROL  MESSAGE 

LOCAL  CIRCUIT  SWITCH  (LCS)  MODE 
TRAFFIC 


5-LEVEL;  PAPER  TAPE  (MART  CONVERTS 
ASCII  TO  ITA2) 
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^ .Am* . Aia L.Aii  «i  * . .  * 


‘.-•V-  ’•"j 


AWEX  2  (cont'd) 

3  RESERVED 

C  RESERVED 

D  CARD,  H0L;.ERITH 

E  RESERVED 

F  CARD,  FLASH  PRECEDENCE 

G  8-LEVEL  ASCII  NARRATIVE,  FLASH 

PRECEDENCE 

H  S-LEVEL  ASCII  NARRATIVE 

S  5-LEVEL  PA2ER  'APE,  F-LASH 

PRECEDENCE  (XART  CCNVERTS  ITA2 
lO  ASCII) 

'T  S-^EVEL  ASCII  NARRATIVE,  I^.MED 

CR  PRIORITY  PRECEDENCE 

U  SERVICE  MESSAGE 

V  SYSTEM  CCNTROL  MESSAGE 

X  LOGGING  INFORMATION 

Undefined,  Spa-^e 
Undefined,  Spare 

'  Device  Characte’"  "T"  is  rescricced  ’O'"  use  with  iressage  '"ev'ew  ce'^rriinal . 

3.  AQRMAT  IDENTIFICATION  CODE  (FIO)  DETERMINATION.  Bits  6  and  7  of  the 
‘^ART/AMPE  SEL  Cha'^acter  a-'e  derived  from  a  code  indicating  the  type  format  of 
the  message.  The  code  will  be  referred  to  as  the  format  identification  code 
(FIC).  The  FIC  will  be  one  of  the  following: 

TYPE  FORMAT  BIT 


Reserved 
DD  173 
JANAP  128 


•w 


rt 


nS\EX  2  (ccr.t'd) 

^^essage  For;rat  SIT 

_ 5  755‘^321 

CSU  22  173  C  0  :  0  1  0  0  1 

Tp,e  orcper  cievice  cnaracter  and  'ts  assccia'ec  device  is  deteniTii ned  from 
errocating  the  DCAC  370-D175-1  SEL  CHAR,  RCV  LMF,  Precedence,  CIC,  DSRI  and 
hcr’zed  Receive  Device  Characters.  There  are  two  exceptions  to  this  r'gid  cross 
•"e  Terence . 


a.  All  f'ash  Precedence  Service  messages  default  to  S-'eve1  ASCII  na'"’"ative,  fla 
Precedence  (SEL  "G" ) . 


y  ■  I  ■  V 


ANNEX  3 

DD  173  Message  Formatting 

1.  This  Annex  prescribes  the  data  line  output  in  CD  IT 3  format  for  a  MART. 
~he  tra'fic  is  orgiinated  at  an  CSU  or  VCD  message  entry  position.  In  either 
case,  the  data  line  output  will  be  standardized  lAW  Appendix  A. 

2.  If  the  messace  is  precared  for  entry  via  the  CSU,  the  following  rules 
apply: 


a.  CD  173  forms  will  be  prepared  using  10  pitch,  CCR  type  set,  A  or  3 
font. 


b.  The  first  character  read  from  the  DD  173  form  will  define  the  left 
margin  of  the  form  (character  position  1).  In  this  case,  page  numbering 
information  in  the  upper  left  corner  of  the  DD  173  form  will  alwys  be  the 
first  charactters( s)  read.  Each  line  is  limited  to  69  characters  including 
positioning  spaces. 

c.  A  set  of  two  carriage  returns  and  one  line  feed  will  be  inserted  by 
the  MART  after  '^eading  each  line  of  the  DD  173  form. 

d.  The  beginning  of  text  is  indicated  by  an  alpha  character 

c‘'assi  fication  other  than  a  predefined  address  prosign,  being  detected  ■' n 
character  position  1  (after  two  or  more  sets  of  two  carriage  returns  and  one 
line  feed  are  sensed  following  detection  of  an  address  field). 

e.  The  word  "SU3J"  or  "SUBJECT"  (on  new  line  -  left  justified)  will 
follow  the  end  of  internal  instructions.  These  instructions  will  be  placed 
at  the  beginning  of  each  section,  as  required  lAW  JANAP  128  during  AMPE 
message  reformatting. 

f.  An  example  of  a  properly  prepared  DD  173/1  form  is  attached  at 
Appendix  B.  TABLE  #3  contains  descriptions  to  specific  fields.  Note  that 
the  page  scan  is  limited  to  20  lines.' 

(1)  The  positioning  indentations  in  the  address  fields  provides 
specific  information  of  continuation  lines  and  multiple  addresses. 

(2)  The  prosign  "XMIT"  is  not  valid  unless  preceded  by  an  AIG  number 
in  the  TO  address  field  or  a  Collective  Address  Indicator  in  the  TO  or  INFO 
address  feidls. 

(3)  The  optional  progisn  "DIST"  is  used  to  indicate  automatic 
routing  by  local  distribution  information.  Each  entry  is  separted  by  a  slant 
(/).  End  of  field  is  indicated  by  a  double  slant  (//).  Both  the  prosign  and 
addressee  entries  will  be  stripped  during  AVPE  JANP  128  message  reformatting 
prior  to  transmission. 

(4)  The  operating  signal  ZEN,  if  used,  will  immediately  precede  the 
PLA  The  PLA  will  begin  in  character  position  20. 


(5)  The  prosign  "ACCT"  is  used  to  indicate  accounting  and  g-'oup 
ount  i nforrati on .  This  prcs’gn,  if  used,  will  follow  all  other  prosigns, 
uring  AYPE  JA\P  123  message  •"9'^OTatt' ng ,  the  "ACCT"  and  accounting 
nfornation  is  piacea  JANAP  123  *or~at  line  10. 

(6)  Co''ti  ruat' on  of  text  on  second  and  succeeding  pages  begins  on 
ine  2.  Although  entries  are  cade  in  line  1  of  all  message  form  pages,  only 
ine  1  entries  from  page  1  are  t'-arsmitted  to  the  AMPE.  Text  is  limited  to  a 
ax’mum  of  20  lines,  69  characters  per  'ine  on  all  continuation  message  form 
aces . 

g.  The  MART  senses  the  last  message  form  page  from  the  i ntrec-^ati on  of 
ne  page  count  field. 

g.  Subsequent  to  sensing  the  last  nage,  the  MART  detects  EOM  upon 
eading  20  lines  of  data  or  four  consecutive  blank  lines  (tht^ee  lines  per 
nch),  whichever  occurs  first. 


m  u> 


T;3L5  =^3  EXPLANATION'  OF 


N.'^'EE!?  S>  TYPE 
OF  CHARACTERS 


"ERyS  TO  DO  -ORy  173/1 


lESCRIPTION  OF  ENTRY 


N. VERIO 

Page  nun:iber. 

N.YERIC 

Total  page  count. 

NUMERIC 

ALPHA 

First  two  digits 
represent  the  day  of 
the  month,  next  two 
digits  represent  the 
hour  of  the  day  using 
the  24  hour  clock,  and 
the  ’ast  two  digits 
represent  the 
mi nutes .  It  wi 1 1  be 
rnntain  thp  ';iiffix  "7" 
indicating  time  in  GMT 

AcPHA 

Authcri zed 
abbreviation  of  the 
current  month. 

NUMERIC 

i-ast  two  digits  of  the 
current  year. 

ALPHA 

Action  precedence. 

AuPHA 

- 

There  must  be  an  info 
precedence  entry  if 
action  field  was  not 
used. 

ALPHA 

Classification 
repeated  4  times. 

ALPHA 

SPECAT  or  SHD 
designator  repeated  5 

iuin 


\.V3ER  &  TYPE 

OF  CHARACTERS 

DESCRIPTION  OF  ENTRY 

2  - 

Language  media  format 
(LKF  information.) 
Leave  blank  unless 
specific  LMF  is 
requi red. 

4  -  ALPHA 

Content  indicator  code 
(CIC),  normally 
"ZYUW."  Other  CICs 
may  be  used  as 
prescribed  in  appli¬ 
cable  directives. 

ALPHA  i\uMERIC 
up  to  12 

A  unique  sequence 
assigned  by  the  Orig 
for  positive  message 
identi fication. 

0  or  3  -  ALPHA 

Book  message  infor- 
ma^ion.  If  "YES"  is 
used,  the  CIC  field 
must  contain  "ZEXW"  or 
"ZYQW." 

VARIABLE.  To  end 
of  line 

Yessage  handling 
information. 

VARIABLE 

Start  of  From  PLA  with 
office  symbol,  if 
avai 1  able , 

VARIABLE 

Start  of  TO  PLA  with 
office  symbol,  if 
available.  If  no 
ACTION  address,  item 

19  applies. 
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XPLANATION  OF  TERVS  TO  DO  FORM  173/1 


R  &  TYPE 

DESORPTION'  OF  ENTRY 

ARACTERS 

7 

20 

VARIABLE 

PLA  continuation 
line(s)  app^'es. 

0  ~  A^rHA 

Type  in  "AIG"  and 
number . 

Start  of  acd’"ess 
indicating  group 
i nformati on . 

9 

:o 

4  -  Alpha 

Type  in  prosign 
"INFO." 

Start  of  information 
line. 

'0 

15 

variae;.e 

P',_A  for  INFO 
addressees . 

- 

15 

Type  in  coerating 
S'ignal  "ZEN." 

Start  of  ZEN 
information . 

1  n 
.L. 

19 

VARIABLE 

Start,  of  Pt-.A(s)  to  be 
delivered  by  other 
than  electrical  means. 

!3 

'  1 

Type  in  orcsign 
"XMT." 

Exempt  prosign. 

1  3 

VARIABLE 

Any  exempted  PLA  when 
AIG(s)  are  used  in  the 
TO  line. 

IS 

1 

VARIABLE 

Start  of  cl assi fi- 
cation  line. 

?6 

1 

4-ALPHA 

End  of  cl  assi  f'’ cation 
i ndi cator 

17 

1 

VARIABLE 

Start  of  text. 

'NO'E:  Tnese 
•.and'i  i  ng , 

entr 

ies 

must  be  made  on  all  sub 

sequent  pages  for  proper 

"'he  fi’-s 
■a'^gin  (ch 

1  h e  uODBT' 

‘nc*  jdirg 

w  C  >  1 

arac 

1  e*  t 
oosi 

a  racier 
ter  posi 
corner 
t  i  0  n  ■■  n  g 

to  apoear  on  the  DO  Fu  ,i  173  will  -define  the  left 
t'on  1).  In  this  case,  page  numbering  information  i 
of  tre  fo’-m.  Each  line  is  limited  to  69  characters 
blanks,  correction  signs,  and  spaces. 

c!'.  -  ,\eqjT  regents  . 

2.1  3er.e'"al  .  This  Secf'cn  establish 
witn  a  '’‘cCLilar  A^'CTIN  ierTiral 
s i gi'a  M>c  supervision,  data  exchange 
'’'C2E  I  a'"d  JAN'A?  12S  prccedL:'"e. 


es  the  reqc'rerent  for  an 
Equipment  (MATE)  and 
,  and  message  p’"ccessing 


1-S  'A  A.yPE  to  interface 
to  provide  lire 
using  L/unC 


2.2  Message  exchange  cetween  tne  Ay,“E  a'-d  the  MATE 
se'ect  c''a'"acte'^s  icentifiec  in  2CAC  370-2175-1. 


will 


utilize  the  standard  set  of 


2.2.1  Messages  transmitted  to  tne  '•‘ATE  will  be  in  JAN'AP  128  format. 

2.2.2  There  are  no  soecial  requirements  for  service  message  text.  Standard 
ccmmun'" cati ons  service  p^'ocedures  will  be  suppo'-ted  by  the  MATE. 

2.3  '•'.essages  received  from  the  MATE  w'll  be  in  jAS'AP  12S  format. 

2.3.1  The  MATE  will  perform  PLA-RI  lookup  and  DD173  to  JANAP  128  conversion, 

2.3.2  The  AM.PE  will  acceot  and  resoond  to  MATE  generated  RM  control  characters  lAW  DCAC 
37C-D175-1. 

2. A  'he  AMPE  will  send/receive  all  media  to/f'‘cm  the  MATE, 
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1.  REq.IRE''‘ESTS 


2.1  Sere’^al  .  The  AV~E  w^'e^'  ccr''’ectec  tc  the  '‘‘ART  is  ’"espcrsib’e  'or 
oe'''crrr,i  rg  the  pr'r.t  exparsicr,  rec..' re-erts  for  var'cts  osers.  The  AX^E  wHl 
■"eceive  ccroressed  resorts  via  AJTCEIN  ir  SC-cclutn  care  ~essage  fcr.tat.  It 
wi  1  ]  orcvice  t"e  cacaci'ity  to  exoard  ard  forwa'-d  the  exoardec  ’'epc'^ts  for 
or-''ti'’g  or  f’e  ‘‘‘ART  p'''rter  ■;  r  132-cra''acter  'orrrat  in  a  ’•ea'i-time  or-iire 
'asr.ior.  ~re  repc'-ts  to  ce  pr-'cec  w’ li  ce  recegrizee  oy  corbi  rations  o*  CIC 
and  RI.  Recognition  'cgic  sna'l  be  based  or  ary  cetbiratien  of  a  rax’''..,r',  of 
2  RI  and  CIC  pairs. 


1.2  Detailed  Recu’ ’'ements .  Reports  to  be  printed  will  be  received  on-line 
via  AUTCCIN.  Trey  will  contain  a  continuous  string  of  deliTieter  characters, 
control  anc  count  characters,  and  characters  to  be  printed.  Strings  of  three 
or  .-'ore  b^anKs  in  the  message  will  have  been  suppressed  by  the  transmitting 
station,  ~he  A'^'PE  must  then  scan  tne  string  of  received  characters,  insert 
the  blanks,  construct  the  p-int  lines,  'insert  tne  proper  select  characters, 
and  transm’t  the  data  to  the  MART  for  printing. 


1.3  Control  Characters. 


1.3. 
si  gn 

T  ^  ^ 


1  Delimiter 
This  is  a 
ICO. 


Character . 

12-A-3  Hoi 


The  delimiter  character  will  be  a  "less  than" 
erith  punch  which  has  the  7-bit  ASCII  binary  code 


1.3.2  Printer  Control  Character.  All  printer  control  character  (PCC)  will 
be  immediately  preceded  by  one  delimiter  character,  e.g.,  “^CC.  Printer 
control  characters  are  de'inea  as  follows; 


Character 

b(blank) 

0(2ero) 

-  (hyphen) 
1 

9  or  c 


Interpretati on 

Space  one  line  before  printing 
Space  two  lines  before  printing 
Space  three  lines  before  printing 
Skip  to  channel  1  before  printing 
(advance  to  top  of  cage  -  'ine  5) 

Sxip  to  channel  9  before  printing 
(advance  to  bottom  of  page  -  line  51) 


1.3.3  Count  Character.  The  character  representing  the  count  will  be  one  of 
the  ASCII  characters  represented  by  the  7-bit  binary  code  1000100  through 
1011010.  The  five  low  order  bits  will  be  utilized  to  correspond  to  decimal 
values  3  through  25.  Note  that  the  corresponding  binary  value  is  one  greater 
than  the  decima'’  value.  The  minimum  number  of  blanks  to  be  reinserted  by 
this  technique  is  3,  the  maximum  is  25.  All  count  characters  will  be 
iimmediately  preceded  by  one  delimiter  character,  e.g.,  cc.  The  count 
characters  are  defined  as  follows: 


■5 


Note  t"at  in  ce*ir, ing  the  orirte*"  con 
chcnacters,  ca^e  was  tave”  to  insure 
S' 'te-'p-'et' ''0  tne  '''tent  o*  t^e  con 


troi  cha''actens  and  the  count 
that  there  wouid  be  no  chance  for 
trol  character. 

f  the  reports  's  the  resocnsio' 1 i t>  of 
ra1  report  paces.  N'o  report  cage  will 
te  reports.  Each  “"eocrt  page  is  to  oe 
'nc  c^aracteri St' cs : 


1.4. 1  S'xt>-six  lines  per  page. 

1.4.2  Six  I  '■  nes  per  inch. 

1.4.3  Each  page  wi'^l  be  11  inches  long. 

1.4.4  bine  5  will  De  the  pos'tion  of  the  first  print  line  on  each  page. 

-'ne  51  will  be  tne  last  line  on  the  page.  Thus  57  print  lines  are  available 
oe*''  cage. 

1.5  Cpe''af'‘ona'!  Requ^-'ements . 

1.5.1  De’it'ter  Sequence.  The  technique  of  data  expansion  uses  a  group  of 
two  control  characters;  the  f'>st  is  always  a  single  delimiter  character 
denoting  the  start  o*  control  sequence.  The  second  character  defines  the 
necessary  acfcn  to  be  taken.  The  control  character  (second  cnaracter)  can 
be  : 

a.  Pr'nter  control  character  -  denotes  beginning  of  a  print  line. 

b.  Count  character  -  denotes  number  of  blanks  to  be  inserted. 

c.  "Less  than"  character  -  denotes  end  of  report. 

1.5.2  Report  Expansion.  When  scanning  for  the  start  of  report,  the  first 
characte"  o*  the  report  should  be  a  <.  After  the  start  of  the  report 
delimiter  nas  been  found,  the  report  will  expanded  using  the  control 
characters,  count  characters,  and  data  characters  until  the  end  of  the  report 
delimiters  (<<)  have  been  ^ound.  The  sequence  is  then  repeated  as  necessary. 

1.5.3  Er-or  Procedures.  Upon  the  detection  of  an  error  in  the  input  data, 
tne  fo.llowing  procedures  shall  be  followed  to  continue  printing  the  report. 

If  no  printer  control  sequence  is  detected  after  all  132-print  positions  are 
accounted  for,  a  print  control  sequence  of  (!  shall  be  inserted  to  preclude 
printing  over  the  previous  line.  In  the  event  the  cha’^acter  following  the 
delimiter  cannot  be  identif'ed  as  one  of  the  defined  characters,  e.g., 
orinte’'  control  character,  count  character,  or  end  of  report  character,  the 
logic  sha’l  cause  the  printer  to  print  a  row  of  asterisks  as  the  next  line, 
advance  to  the  top  of  a  new  page,  print  an  "invalid  control  character", 
substitute  a  blank  for  that  character  and  continue  the  line  expansion  and 
printing  process.  The  blank  expansion  of  the  format  print  buffer  over  132  or 
an  invalid  character  will  cause  "Blank  Expansion  Error"  to  be  printed.  More 
tnan  132  p''"'nter  line  columns  formatted  without  a  following  delimiter/control 
character  comb'nation  will  cause  the  message  "Print  Line  Exceeds  132".  When 
one  of  the  tnree  errors  is  detected  causing  the  error  will  be  printed  on  a 
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•>i  APPENDIX  C:  IRT  Interface  Reauirer’ent 

I 


I 


V**". 


Re-.ote  7e''~i '-Ire  -arcler  (yC"IRT) 


gv-  •  s  jsec  zc 


'caze  'r  a  *j11  d-jplex, 


'.1  -eta'.ec  -escript'cr 

a.  The  IRT  yc?  "'ire  hard'e’'  is  a  *-il  c-r-lex,  r '  cc<-by-b  I  ock 
;c: — ^^-r  cat' or  s  ir.te''*ace.  A'll  i-.c-t  "essages  a-'e  fra~ec  cy  fcur  cor.trol 
:'ra’"acters  a-c  message  text  is  £0  c^a’"acters  in  length,  as  sncwr  in  F'gure 


D.  ~he  IRT  is  not  a  poilaole  device;  it  transmits  to  the  AMPE  wnen  it 
has  data  available  and  is  'n  a  constant  ready  to  receive  mode.  It  is 
co''t’"o'' I ed  by  data  ack’^owledg?  (ACk)  secuerces  oassed  between  the  IRT  and  the 
A'''?E  and  by  '•ecogn •  ti on  of  tne  EC*''  secjence.  A*ter  each  block  is  transmitted 
no  -‘crther  cata  'is  sent  until  tne  cor'^ect  control  sequence  is  rece'ved.  If  a 
■'egative  acknowledge  (NAK)  seque''ce  is  rece'ved,  the  same  block  is 
"etrar smi tted .  If  a  wait  befc'e  transmit  (’w3T)  is  received,  a  three  second 
timer  is  set:  and  a*ter  the  time’"  expires,  the  sane  block  is  retransmitted. 

I*  "0  answer  is  -"eceived  a*te’"  three  seconds,  the  bloCK  's  ’"etransmi tted . 
rt'he^ever  an  ACK  is  rece'ved,  tne  "ext  block  is  sent. 


c.  At  initialization,  a  delete  message  (CM)  is  expected  and  sent.  The 

,  correct  control  sequence  -"esocnse  's  ACK  and  the  alternating  duplicate  b'ock 
protect  bit  is  set  to  its  initial  state.  A  ’-eject  message  (RM)  control 
sequence  is  t^-en  sent.  In  normal  ope'-ation,  the  alte’-nating  duplicate  blouk 
orotect  in  the  select  (SEL)  c’-aracter  is  toggled  for  each  block. 

d.  I*  the  IRT  circuit  is  up  and  in  icle  state,  the  line  handle-" 
initiates  a  DM  control  sequence  to  determine  the  cur'-ent  status  of  the  IRT 
and  its  communications  line.  If  the  IRT  does  not  resoond  with  an  ACK  control 
sequence,  the  ooerator  is  notif'ed  that  this  circuit  did  not  respond  and  the 
circuit  is  logged  down. 

e.  'when  receiving,  the  lire  terminal  is  looking  for  sequential 
synchronous  (SYNC)  characters  oefore  the  stare  of  header  (SDK).  All  leading 
and  tra’ling  SYcNC  cha’"acte’"s  a-e  st’-iooed  off  by  the  line  terminal.  V.'he:"  SOH 
is  detected,  the  line  terminal  passes  data  until  the  end  of  text  block  (ETB) 


S  S  S 


GET 
H  L  X 


(80  characters) 


FIGURE  A-3.  IR’  LI'xE  HANDLER  BLOCK  FORM.AT 


•  » 


ere  cf  text  (ETX)  is  er.ccjrtered.  The  irp^e  bioc<  is  crecsec  for  correct  cor.tro’. 

;’'  =  -3cter  secoerces  arc  bioc<  parity.  If  the  •''pjt  data  blccs  is  '"ecelved  'n  error,  a 
N-\  is  se"t.  I*  bj'fer  space  fo'^  the  rext  b^ocv  is  te-oorar-'y  '-''available,  a  .‘.'ST  is 


;e''t  arc  a  ore  arc  or,e-ra  r  seccrc  : 
;ata  clcc\  is  received  correctly  arc 

c  <-3r--  -ns  ■'■•’I  I* 


■er  's  set  to  acc-'re  tre  Dur*er 


tr.e  irout 


3es  rot  cortai''  ar  EC^,  an  AC.K  corf^ol  secterce 
£TX,  tre  IRT  lire  hardier  wa^'ts  *or  ECMI''.'  to 


's  sent.  1'  the  iroot  block  cc''ta'rs  ar  £TX,  tre  IRT  lire  hardier  wa^'ts  *or  ECMI''.'  to 
set  se''c  ACv  t'c-  tre  tra-'e-.  ''■"e  IRT  'ire  rard'er  a' so  C''ec‘sS  if  ary  of  tr.e  ccrt^oi 

w  Ta  *  w  W0C  '^0C6*V8G.  I*  SC  t.n0  CCS*^c*C!^  iS  r’CC'f'SC  Cnat.  ChiS 

I*\’  is  ir.  lcccbQC^  arc  t''e  circjit  is  Iccged  c'ca'^. 

f.  All  nessace  characters,  including  the  block  oarity  chai^acter  (3PC),  and  all 
cort’''ol  characters  have  odd  character  parity.  The  BPC  produces  block  parity  for 
ore  througr  seven  of  all  characters  except  the  S'^'NC  and  SOH  characters.  Acescrip 
of  the  IRT  control  character  is  listed  in  Table  VIII. 

g.  r-gi^re  R-9  is  a  schem.atic  illustration  of  the  IRT  traffic  flow  through  the  A'^'PE 
Systen, 

1.2  B'^ffe’''  Fo'—ats.  ^.C^IR'i'  uses  the  standarc  V.C?  cor.runi cati or s  bur’fers  and  stancard 


.2  Syster  “''cdule  References.  MCPIRT  checks  CXDD  arc  CC‘''.'''.CN . 

,A  Queues.  VCRIRT  uses  “''CP's  cueues. 

.5  Interfaces.  VCP  g'Wes  control  XCPIRT,  and  control  1s  re''eased  to  .‘''QP. 


rt  CT 


reject  'ressage;  sert  by  receiver  zo 
cause  transmitted  message  to  cancel 
current  message  ce'.nc  f-ansmi tted . 

End  of  data  for  card  messages  or  end 
of  screen  for  VDU  entries  and  control 
sequences . 

End  of  ohys'cal  block  for  card 
messages  or  end  of  physical  line  for 
VDU  entries. 

Positive  acknowledge;  dual  sequence 
(ACK  ACK)  response  for  valid  message. 
Negative  acknowledge;  dual  sequence 
(NAK  NAK)  response  for  message  in 
error. 

Wait  before  transmit;  response  to  a 
valid  data  block  to  inform  transmitte 
that  receiver  can  no  longer  accept 
data . 

Data  link  escape;  defines  next 
contiguous  character  as  resulting 
from  IRT  operator  depressing  one  of 
16  auxiliary  function  keys. 

Delete  message;  sent  by  the 
transmitter  to  cause  the  receiver  to 
cancel  the  cur''ent  message  being 


received . 


Tiguxe  l-T'l.  Initial  header  preparation  mask. 


_ ColuiTin _ I _ 

Tilllll”ill2222  22  2222333333333344'14444'14  4  3S555555556666666666777  7  777 
1234  5673901 234  567  0901 23 4  567  89 01234  567  090 1234  56 7  HQ  vO  12 34  347  0901  7. 14  RO  m  ?  1 4  sn 


Figure  1-2.  Continuation -xaask. 


iarv  sy 


..1  je^aiiec  ^esc’" ; p^i on  . 

a.  The  VC?  DPI  ' ' ’-e  nandler  enso:-es  ohat  all  daoa  deinc  f"arsr:  ored  a’'G 
’"ece'vec  to  or  fror  the  D^I  has  tre  correct  olocK.  fortat,  oan'ty,  length,  and 
control  framing  character's. 

b.  31ock  parity  is  computed  in  accordance  with  nontransparent  binary 
synchronous  procedures.  The  block  parity  character  is  generated  to  induce 
the  first  data  char-acter  after  the  SOH  or  STX  char-acter  and  also  the  ETC  or 
ET3  c'^’er'acter .  All  characters  transm'tted  and  received  a^e  ASCII  characters 
with  CDD  PARITY. 


c.  All  data  transmissions  are  verified  by  control  messages;  i.e., 
ACK/N'AK/ENQ.  No  idle  cnaracters  are  generated  between  data  transmissions. 

C.  At  initialization,  an  EOT  control  sequence  must  be  transmitted  and 
cetected  before  any  processing  can  occur. 


e.  Whan  receiving  input 
cha-acters  be'ore  any  input 
characters  are  deleted.  For 
character.  SOH  indicates  an 
containing  a  message  header, 
character  of  each  succeeding 
intermediate  data  block  will 
block  is  indicated  by  an  ETX 
be  .neader. 


the  line  terminal  looks  for  two  sequential  SYNC 
s  passed  to  the  DPI  line  hand'er,  and  ad  SYNC 
an  input  header,  SOH  is  the  f'rst  valid 
80  byte  data  buffer  (plus  control  characters) 
After  receiving  the  SOH  block,  STX  is  the  first 
block  until  either  ETX  or  EOT  is  received.  Each 
end  with  an  STB  control  character;  the  last  data 
After  the  ETX  block,  the  next  cata  block  must 


*.  Data  block  sizes  vary  from  a  minimum  of  SO  characte'"  (olus  *'"aming 
cha’-acters)  to  a  maximum  of  2000  characters  (plus  framing  characters).  To 
ensure  line  synchronization,  SYNC  characters  are  suffixed  to  each  data  block. 
Afte"  each  b’ock  is  transmitted  o’"  received,  no  further  Cata  blocks  are  sent 
until  the  proper  control  sequence  is  received. 

g.  See  Table  IX  for  a  list  of  the  DPI  control  characters  and  their  use. 


h.  Timeouts  are  used  to  prevent  indefinite  data  link  hangups,  by 
providing  a  fixed  time  within  which  all  responses  must  occur.  Transmit 
timeouts  will  be  one  second;  receive  timeouts  will  be  three  seconds;  and 
continue  timeouts  (WACK)  will  be  two  seconds. 


Descri  c  f!  on _ 

Precedes  a  neacer  Diock 

Precedes  a  block  of  text  characters 

Indicates  end  of  text  block 

Indicates  end  of  message  that  has  one 

or  more  blocks 

Indicates  end  of  t'^ansmi  ssion 
Enquiry;  used  to  obtain  a  repeat 

transmission  or  a  bid  for  the  line 
Positive  acknow’ edcment 
Positive  acknowledgment 
Wait  before  transmit 


Negative  acknowledge;  indicates  a 
previous  block  received  in  error 
Initiated  by  the  DPI  to  allow  AMPE 


All  Z?l  circuits  are  defined  in  a  unique  AMPE  system  T,anner  by  four 


na-acters 


(1)  Tne  first  cnaracter  of  the  circuit  nodule  rare  is  II. 

(2)  The  second  characte'^  de'ines  the  particu''ar  DPI  in  the  the  AXPE 
systen.  Tne  systen  '"eserves  t'e  cna’-acters  C,  Q,  R,  and  Y. 


'acter  can  be  any  a'chabetic  cha’^acter. 


(A)  The  fourth  character  can  be  any  alphabetic  characte-"  except  A, 
?,  or  S.  These  cha'^acters  are  reserved  as  follows; 

(a)  A  defines  the  DPI  active  circuit, 

(b)  P  de'f'ines  the  DPI  p’^oblem  batch  files. 

(c)  S  defines  the  DPI  service  file. 


j.  Gn  outbound  DPI  messages,  a  SOH  framed  packet  is  83  characters  in 
'ergth.  A  STX  framed  packet  can  be  a  maximum  of  2003  ch.a'"acters ,  including 
'"naming  character,  and  a  minimum  of  83  characters  in  length.  Figure  4-11  is 
an  example  of  two  outbound  messages;  the  first  is  25  line  blocks  in  length 
a-d  the  second  is  AS  line  blocks. 

k.  On  inbound  DPI  messages,  a  SOH  should  only  be  p’aced  on  packets 
ccnmaining  preamble  or  JAN'AP  128  headers.  A  unique  character  follows;  e.g., 
an  ASCII  lowe'"  case  m.  An  example  of  a  500  line  block  message  would  be 
*ra~ed  and  packeted  as  shown  in  Figure  4-12. 

l.  File  ’■equest  and  statistics  request  control  messages  outbound  *’rom 
the  DPI  to  AXPE  consist  of  single  line  block  messages  which  are  framed  as 
shown  in  Figures  4-13  and  4-lA,  respectively. 

m.  In  orde’"  to  accommodate  I3Y  2701  hardware  recui -ements ,  two 
syncnronous  cnaracters  are  added  to  all  line  blocks  transmitted  from  AMPE  at 
the  requ'’’’"ed  '"requency.  Frequency  is  determined  by  line  speed  and  data 
blocking  “actor. 

1.2  Buffer  Formats.  MCPDPI  uses  standard  MCP  communications  buffers. 

1.3  System  Module  Reference.  MCPDPI  accesses  circuit  modules  and  AMPE 
common . 

1.4  Queues.  MCPDPI  uses  MCP  queues. 

1.5  Interfaces.  MCPDPI  inte’^faces  with  MCP. 
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SECTION  1.  GENERAL 


1.1  Puroose 


The  objective  of  this  document  is  to  provide  a  programming  guide  for  attaching 
a  Remote  Computer  to  the  Honeywell  DATANET  355  (DN-355)  Remote  Terminal  Super- 
v'isor  (CRTS)  under  the  Remote  Computer  Interface/Direct  Access  Convention 
(RCI  'DAC)  for  subsequent  inclusion  to  the  NMCS  Automated  Control  Executive 
(NACE).  This  document  is  not  intended  to  replace  existing  documentation  on 
this  subject  but  is  to  supplement  them  in  areas  which  are  not  clearly  defined. 

1 . 2  Equipment  Configuration 

In  order  for  a  remote  computer  to  send  or  receive  message  traffic  from/to  NACE, 
the  remote  computer  must  be  physically  connected  (hard  wired)  to  a  port  of  the 
DN-355.  Remote  computers  must  be  configured  in  the  DN-355  Startup  (BOOT)  deck. 
The  DN-355  can  handle  up  to  200  remote  computers  or  terminals  simultaneously  with 
varying  rates  of  transmissions  ranging  from  110  bits  per  second  to  50,000  bits 
per  second. 

1.3  Protocol  Convention 


The  communication  line  discipline  (protocol)  used  by  the  DN-355  and  NACE  is  the 
RCI/DAC  convention.  In  the  convention,  the  remote  computer  operates  in  a  message 
response  mode.  Only  the  operations  defined  within  the  RCI/DAC  interface  can  be 
used  by  the  remote  computer,  operating  with  the  DN-355,  to  communicate  with  NACE. 

The  benefits  of  RCI/DAC  are  that  it  provides  error  checking  and  recovery  procedures 
to  assure  that  no  data  are  handled  more  than  once  and  are  error  free  when  received. 
This  interface  also  allows  NACE  and  the  remote  computer  to  communicate  directly 
with  each  other  via  the  DN-355. 


SECTION  2.  SYSTEM  DESCRIPTION 


Remoce  computers  must  satisfy  the  requirements  of  the  RCI/DAC  interface. 

Basically,  RCI  'DAC  requires  that  information  and  control  records  transmitted 
be  in  the  format  specified  in  Figure  1.  Where  applicable,  the  remote  computer 
must  acknowledge  (either  positively  or  negatively)  each  message  sent  by  the 
DN-355. 

2 . 1  General  Description 

Remote  computers  which  are  to  be  used  to  send/receive  message  traffic  to  NACE 
via  the  DN-355  must  initially  send  to  the  DN-355  a  SELECT  command  which  will 
logically  connect  the  line  to  the  DN-355.  The  DN-355  will  respond  by  acknowledging 
the  SELECT  with  a  "Clear  to  Send"  message.  The  remote  computer  must  respond  with 
the  log-on  USERID$PASSWORD  that  was  issued  for  that  remote  computer.  The  DN-355 
will  validate  the  USERID$PASSWORD  and  send  to  the  remote  computer  an  acknowledgement. 
Upon  receipt  of  the  acknowledgement,  the  remote  computer  must  issue  the  DAC  NACE-U 
command.  This  command  instructs  the  DN-355  to  logically  connect  the  communication 
line  from  the  remote  computer  to  NACE.  The  DN-355  will  then  send  a  security  message 
(25  words)  which  the  remote  computer  must  acknowledge  (ACK).  The  DN-355  will  also 
send  the  Terminal  ID  of  the  line  to  NACE  which  will  verify  that  the  remote  computer 
is  known  to  it.  If  the  Terminal  ID  is  not  known  to  NACE,  it  will  disconnect  the 
line.  If  the  Terminal  ID  is  known  to  NACE,  it  will  issue  a  READY  command  to  the 
remote  computer.  The  remote  computer  must  acknowledge  with  the  appropriate  command 
to  which  the  DN-355  must  ACK.  With  this  ACK,  both  the  remote  computer  and  NACE 
are  in  the  Active  RCI/DAC  mode  (see  paragraph  2. 1.2. 2).  This  two-way  exchange  of 
messages  continues  until  termination  by  either  NACE  or  the  remote  computer. 

2.1.2  Modes  of  Operation.  Under  the  RCI/DAC  interface,  there  are  two  modes  of 
operation.  They  are  the  Idle  mode  and  the  Active  mode. 

2. 1.2.1  Idle  Mode.  In  the  Idle  mode,  no  messages  are  exchanged:  but  the  remote 
computer  line  remains  logically  connected  to  the  DN-355.  If  the  line  remains  idle 
for  seven  minutes,  the  DN-355  will  disconnect  the  line.  While  in  the  Idle  mode, 
the  remote  computer  must  be  ready  to  transmit  a  "SELECT"  or  "Ready  for  Disconnect" 
control  message. 

2. 1.2. 2  Active  Mode.  When  both  lines  of  the  remote  computer  and  NACE  are  logically 
connected,  and  a  "READY"  control  message  is  received  by  the  DN-355  from  either  the 
remote  computer  or  NACE,  the  Active  mode  of  Operation  is  entered. 

During  the  Active  mode  of  operation,  the  remote  computer  must  be  prepared  to  accept 
any  of  the  following  messages: 

*  Information  messages  with  or  without  data. 


r  t  -w  -9^  : 


Synchronization  Character 


Start  of  Header 
Format  Code 
Sequence  Code 
Address  Code 
Operation  Code 
Identification  Code 
Start  of  Text 


Data  (not  to  exceed  324  characters) 


End  of  Text  or  End  of  Text  Block  (ETB) 
Block  Check  Character 


FIGURE  1.  Control  Record  Format 


*  Special  control  messages 

*  Service  messages 

-  Terminate 

-  Ready  for  disconnect  ^ 

-  Disconnect 

After  transmitting  a  message  to  the  remote  computer,  the  DN-355  begins  a 
7-second  timeout.  If  no  response  is  received  from  the  remote  computer  within 
seven  seconds,  the  DN-355  retransmits  the  last  message  with  the  same  Sequence 
Code  and  a  negative  acknowledgement  (NAK) .  A  "Terminate  Service"  message  from 
either  NACE  or  the  remote  computer  initiates  a  return  to  the  Idla  mode.  A 
Terminate  message  may  be  sent  at  any  time  during  Active  mode. 

2. 1.2.3  Line  Disconnection.  When  the  disconnect  function  is  sent  to  the 
DN-355,  the  following  service  messages  are  sent: 

*  Ready  for  Disconnect  (RFD)  -  No  reason  for  the  disconnect  is  sent  to 
the  DN-355.  The  DN-355  responds  with  a  RFD  with  the  message  "LINE 
DISCONNECTED  CP"  and  the  line  is  logically  disconnected. 

*  Disconnect  -  If  the  DN-355  receives  a  disconnect,  the  line  is  immediately 
disconnected  without  answering  the  message. 

When  the  disconnect  is  received  from  NACE,  the  DN-355  ensures  that  the  line  is 
disconnected  from  NACE  and  that  any  activity  on  the  line  (input  or  output)  is 
destroyed . 

2 . 2  Detail  Description 

Once  logically  connected  to  NACE  via  the  DN-355,  all  communications  are  carried  out 
in  the  form  of  Information  and  Control  records.  Information  messages  may  be  sent 
with  or  without  text.  Text  refers  to  a  message  with  data  between  the  Start  of  Text 
(STX)  and  End  of  Text  Code  (ETX). 

2.2.1  Information  and  Control  Record  Format.  All  messages  must  be  transmitted  in 
the  format  as  depicted  in  Figure  1. 

2. 2. 1.2  Synchronization  Character  (SYN).  Two  or  more  consecutive  synchronization 
characters  (octal  026)  must  be  recognized  by  either  the  remote  computer  or  the  DN- 
355.  This  assures  that  the  two  systems  are  synchronized  before  data  transmission 
begins,  thus  reducing  the  possibility  of  lost  or  erroneous  data.  It  is  recommended 
that  at  least  four  SYNs  be  used. 

2. 2. 1.3  Start  of  Header  (SOH).  The  SOH  (octal  001)  indicates  the  beginning  of 
the  message. 

2. 2. 1.4  Format  Code  (FC).  The  FC  specifies  the  purpose  and  the  format  of  the 
text  in  the  message.  The  FC  directs  the  DN-355  as  to  what  action  is  required  to 
handle  the  message. 
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2. 2. 1.4.1  Control  Record.  No  Compression.  This  FC  (octal  104)  is  used  by  either  the 
remote  computer  or  the  DN'-355.  The  text  of  the  message  is  not  compressed  and 
contains  only  one  control  record. 

2. 2. 1.4. 2  Control  Record.  Compression.  This  FC  (octal  105)  is  only  used  by  the 
remote  computer.  The  text  may  be  compressed  and  may  contain  one  record. 

2. 2. 1.4. 3  Information  Message,  No  Split,  No  Compression.  This  FC  (octal  110) 
when  used  specifies  that  the  text  must  not  be  compressed.  Th»  text  may  contain 
multiple  records,  but  all  of  them  must  be  complete  within  the  message.  Each 
record  must  be  enclosed  by  a  Message  Media  Code  (MMC)  and  a  .Record  Separator  (RS). 

See  Figure  2.  A  MMC  must  follow  the  STX  and  a  RS  (octal  036)  must  precede  the  ETX. 

2. 2. 1.4. 4  Information  Message,  No  Split,  Compression.  This  FC  is  octal  111.  The 
text  of  a  message  with  this  FC  may  je  compressed,  but  the  text  must  contain  comple*;e 
records.  The  text  may  contain  multiple  records.  Each  record  must  be  enclosed  by 

a  MMC  and  a  RS .  A  MMC  must  follow  the  STX  and  the  RS  must  precede  the  ETX. 

2. 2. 1.4. 5  Information  Message,  Split,  No  Compression.  This  FC  (octal  112)  specifies 
the  text  is  not  compressed,  but  records  in  the  text  may  be  split  across  messages. 

An  incomplete  record  at  the  end  of  the  message  is  continued  after  the  STX  of  the 
next  message.  The  text  may  contain  multiple  records. 

2. 2. 1.4. 6  Information  Message,  Split,  Compression.  This  FC  (octal  113)  specifies 
the  text  may  be  compressed  and  records  in  the  text  may  be  split  across  messages. 

An  incomplete  record  at  the  end  of  a  message  is  continued  after  the  STX  of  the  next 
message.  The  text  may  contain  multiple  records. 

2. 2. 1.4. 7  Information  Message,  User-Defined  Text.  This  FC  (octal  115)  specifies 
the  text  of  a  message  may  be  in  any  format  agreeable  between  the  remote  computer  and 
NACE.  NACE ,  to  properly  perform  its  designed  functions  in  the  area  of  message 
routing,  needs  more  control  information  about  the  message  being  received.  This 
information  is  provided  in  the  form  of  Message  Media  Codes  (MMC).  See  Figure  2. 

These  MMC  codes  will  be  the  first  characters  transmitted  after  the  STX  and  RS 
characters . 

2.2. 1.5  Sequence  Code  (SC).  This  code  is  used  to  insure  that  data  is  neither 
lost  nor  used  more  than  once.  This  code  alternates  between  octal  101  and  102.  A 
changed  SC  indicates  new  text  when  text  is  present.  The  following  rules  concerning 
the  use  of  SC  apply  equally  to  the  remote  computer  and  the  DN-355.  After  transmitting 
a  message  to  the  remote  computer,  the  DN-355  begins  a  seven-second  timeout.  If  no 
response  is  received  from  the  remote  computer  within  seven  seconds,  the  DN-355  re¬ 
transmits  the  last  message  with  the  same  SC  and  a  negative  acknowledgement  (NAK) . 


Receiving  Messages  with  the  Same  SC 


a.  When  the  text  of  the  message  is  received  in  error,  retransmit  the  last 
message  with  a  NAK  and  the  same  SC. 


b.  When  the  SC  is  the  same,  the  message  was  received  error-free  with  an  ACK, 
and  the  text  of  the  message  has  already  been  processed,  alter  the  SC  and 
transmit  the  next  message  (with  or  without  message  text)  with  an  ACK. 
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Figure  2.  Message  Media  Codes 
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c.  When  the  SC  is  the  same,  the  message  was  received  error-free  with  an 
NAK  and  the  text  of  the  message  has  already  been  processed,  retransmit 
the  last  message  with  the  same  SC  with  an  ACK. 


d.  When  the  SC  is  the  same  and  the  received  message  is  in  error  and  contains 

no  text,  retransmit  the  last  message  with  a  NAK  and  the  same  SC. 

e.  When  the  SC  is  the  same  and  the  received  message  is  error-free,  contains 

no  message  text  and  contains  an  ACK,  alter  the  SC  and  transmit  the  next 
message  with  an  ACK  and  new  message  text. 

f.  When  the  SC  is  the  same  and  the  received  message  is  error-free,  contains  no 
message  text  and  contains  an  NAK,  retransmit  the  last  message  with  the  same 
SC  and  an  ACK. 


Receiving  Messages  with  Different  SC 

a.  When  the  SC  is  different  and  the  received  message  text  is  error-free  and 
contains  an  ACK,  process  the  message  text,  alter  the  SC  and  transmit  the 
next  message  with  an  ACK. 

b.  When  the  SC  is  different  and  the  received  message  text  is  error-free  and 
the  received  message  contains  an  NAK,  process  the  message  text,  alter  the 
SC  and  transmit  the  next  message  with  an  ACK.  (The  message  text,  being 
transmitted  in  one  direction  was  received  error-free). 

c.  When  the  SC  is  different  and  the  received  message  is  error-free,  contains 
no  message  text  and  contains  an  ACK,  change  the  SC  and  transmit  the  next 
message  with  an  ACK  and  new  message  text. 

d.  When  the  SC  is  different  and  the  received  message  is  error-free,  contains 
no  message  text  and  contains  an  NAK,  retransmit  the  last  message  with  the 
same  SC  with  an  ACK. 

2.2. 1.6  Address  Code  (AC).  Although  the  AC  (octal  100)  is  not  used  by  either  the 
DN-355  or  NACE ,  it  is  a  part  of  the  standard  interface  and  must  be  included  in  the 
message  format. 
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2. 2. 1.7  Operations  Codes  (PC).  The  OCs  specify  the  operations  to  be  performed  and 
describe  the  acknowledgements  which  may  be  given.  Bit  7,  the  Most  Significant  Bit 
(MSB),  is  always  a  one.  Bits  4-6  contain  the  acknowledgement  code.  The  DN-355 
will  only  send  a  positive  acknowledgement  (ACK)  000,  or  the  negative  acknowledgement 
(NAK)  001.  The  DN-355  will,  however,  recognize  all  NAK  codes.  Bits  1-3  define  the 
instructions  which  specify  the  operations  to  be  performed. 

a.  Acknowledgement  Codes 
BIT  POSITION 


6  5  4 


Description 


Positive 
Negative 
Negat ive 
Negative 
Negative 
Negat ive 


Acknowledgement 

Acknowledgement 

-  BCC  in  error 

-  Char  Parity  error 

-  SC  in  error 

-  OC  in  error 


Negat ive 


STX  missing 


Negative 


ETX  missing 
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b.  Operations  Codes 

BITS  OPERATION  OPERATION 

3  2  1  INSTRUCTION  SPECIFIED 

000  No  Request  This  instruction  neither  requests 

nor  inhibits  the  sending  of  message 

text.  (Used  to  send  ,an  ACK  with  new 
message  text) . 

Indicates  the  remote  computer  is 
ready  to  transmit  data.  After  the 
DN-355  has  accepted  a  SELECT,  all 
preceding  SELECTS  are  ignored  until 
the  line  is  placed  in  an  Idle  Mode. 

Oil  Terminate  Informs  the  received  that  no  more 

messages  are  to  be  transmitted,  but 
the  line  is  to  remain  connected  (Idle 
mode).  Both  NACE  and  the  remote  com¬ 
puter  must  remain  ready  to  receive  messages. 

100  Ready  for  Informs  the  receiver  that  the  sender  is 

Disconnect  going  to  disconnect  the  line. 

110  Disconnect  Informs  the  receiver  that  the  sender  is 

disconnecting  the  line.  No  reply  is  expected 
and  both  stations  are  to  disconnect  the  line. 

2. 2. 1.8  Identification  Code  (IC).  The  IC  (octal  100)  is  not  used  by  NACE  or  the 
DN-355  but  is  part  of  the  standard  interface  and  must  be  included  in  the  message 
format . 

2. 2. 1.9  Start  of  Text  (STX).  The  STX  (octal  002)  defines  the  beginning  of  the  textua 
portion  of  the  message. 

2.2.1.10  End  of  Text  (ETX).  The  ETX  (octal  003)  defines  the  logical  end  of  the 
textual  portion  for  the  message.  (Not  necessarily  the  physical  end  of  the  text). 

2.2.1.11  Block  Check  Character  (BCC).  The  BCC  is  an  exclusive  OR  of  the  message 
characters  following  the  SOH  and  up  to  and  including  the  ETX.  Since  the  DN-355  checks 
for  odd  pairty,  the  BCC  must  also  be  odd  parity. 

2.2.2  Data  Compression.  When  the  message  text  contains  three  or  more  of  the 
same  data  characters,  these  characters  may  be  compressed  to  reduce  the  number  of 
characters  to  be  transmitted.  The  format  used  to  compress  consectuive  characters  are 
as  follows:  X,  US  and  CC. 

where,  X  -  is  the  character  to  be  compressed 
US  -  Compression  indicator  (octal  037) 

CC  -  A  count  of  the  number  of  times  the  character  is  to  be 
repeated.  (Maximum  of  63) 


010  Select 

(Send  Data) 


■  Tr'.7r"sr-T>' 
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This  data  compression  technique  permits  compression  of  the  multiple  occurrence 
of  any  character  and  also  allows  for  compression  of  multiple  occurrences  of  sets 
of  characters  within  the  same  record.  When  compression  is  specified,  the  DN-355 
checks  each  input  character  to  determine  if  it  is  the  compression  character.  This 
character  is  used  to  expand  the  input  for  transmission  to  NACE . 

2.2.3  Message  Media  Codes  (MMC).  The  MMC's  used  by  the  remote  computer  and  NACE 
are  described  in  Figure  2.  The  MMC's  are  a  sub-level  of  the  ^C1,DAC  interface  and 
as  such  are  of  little  concern  to  the  DN-355.  The  MMC's  describe  the  type  of 
message  being  received,  i.e.,  single-record  or  AUTODIN,  the  security  classification 
of  the  message  and  other  control  information.  Through  the  use  of  NNC's,  NACE  and 
remote  computers  coordinate  the  sending/receiving  of  message  data  such  as  WAITS,  NO 
DATA  NOW,  and  CANCEL. 

2. 2. 3.1  Message  Format.  Message  text  will  be  broken  down  into  message  segments. 

(A  message  segment  is  construed  to  be  all  characters  after  the  synchronization 
(SYN)  and  before  the  BCC  and  must  contain  no  more  than  1272  characters).  A  segment 
will  contain  a  maximum  of  16  line  blocks  of  80  text  characters.  Each  message 
segment  will  contain  complete  line  blocks.  Compression  of  text  and  the  truncation 
of  trailing  blanks  is  permitted.  Each  line  block  within  a  segment  will  be  preceded 
by  a  MMC  and  will  be  followed  by  a  record  separator  (octal  036).  The  MMC  will 
contain  information  about  the  line  block  that  follows. 


2.2,^  Ready  Messages.  This  message  is  sent  when  either  NACE  or  the  remote  computer 
has  messages  to  transmit.  The  format  of  this  control  message  is  as  follows: 

S'lN,  SYN,  SYN,  SYN,  SOH ,  FC ,  SC,  AC,  OC ,  IC,  STX,  FG ,  NULL,  RS ,  ETX ,  BCC 


where,  FC  =  115 

OC  =  100 

FG  =  MMC  denoting  Ready 

NULL  =  100 

RS  =  036 


After  each  command  sequence  is  completed,  the  remote  computer  places  his  communi¬ 
cation  line  in  the  receive  position  and  waits  for  the  next  command  from  NACE.  The 
assumption  here  is  that  NACE  always  has  something  to  do.  This  is  not  always  true 
as  NACE  may  be  waiting  to  receive  more  data. 


2.2.4. 1  Auxiliary  Field.  The  purpose  of  the  auxiliary  field  is  to  indicate  to 
the  DN-355  which  message  data  formats  are  to  be  used  for  message  data  from  the  remote 
computer  to  the  DN-355.  The  auxiliary  field  is  used  only  in  the  SELECT  and  DAC  control 
messages  and  only  one  auxiliary  field  is  permitted  per  control  message.  The  DN-355 
does  not  transmit  any  auxiliary  fields.  When  no  auxiliary  field  is  used,  the 
message  data  to  the  remote  computer  will  be  compressed  and  edited,  and  may  be  split 
across  message  segments.  The  auxiliary  filed  is  as  follows: 


Codes  in  ASCII 


RECEIVE 

TRANSMIT 

COMPRESSION 

EDIT 

100 

113 

Yes 

Yes 

101 

111 

Yes 

Yes 

102 

113 

Yes 

No 

103 

111 

Yes 

No 

104 

112 

No 

Yes 

SPLIT  RECORDS 

Yes 

No 

Yes 

No 

Yes 


RECEI\T 


TRANSMIT  COMPRESSION  EDIT 


SPLIT  RECORDS 


105 

110 

No 

Yes 

No 

106 

112 

No 

No 

Yes 

107 

110 

No 

No 

No 

2 . 2 .4 . 2 

Special 

Control  Messages. 

The 

Spec ia 1 

reraote  coraputer  to  transmit  instructions  or  operational  info^ation  to  the  DN-355 
and  NACE .  They  are  used  for  initiating,  acknowledgement  and  terminating  information. 
The  format  for  Special  Control  Messages  are  as  follows; 

2. 2. 4. 2.1  Special  Control  Message,  No  Auxiliary  Field. 

SYN,  SYN,  SYN,  SYN ,  SOH,  FC ,  AC,  OC ,  IC,  STX ,  ETX,  BCC 

This  format  may  be  used  for  all  Special  Control  Messages  to  the  DN-355. 

2. 2. 4. 2. 2  Special  Control  Messages,  Auxiliary  Field. 

SYN,  SYN,  SYN,  SYN,  SOH,  FC ,  AC,  OC ,  IC,  AUX  FIELD,  STX,  ETX,  BCC 


This  format  may  optionally  be  used  by  the  remote  computer  when  sending  a  SELECT 
to  the  DN-355.  The  DN-355  never  sends  this  message.  The  FC  used  in  a  SELECT 
message  is  octal  103. 
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SECTION  3.  INP’JT/OUTPUT  DESCRIPTION 

3 . 1  General  Description 

Users  of  the  RCI  'DAC  interface  must  be  aware  that  the  remote  computer  is  sub¬ 
ordinate  to  the  DN-355  and  NACE.  Once  logically  connected  to  NACE ,  the  remote 
computer  responds  to  commands  from  the  DN-355  and  NACE.  The  remote  computer  must 
send  acknowledgements  for  all  control  messages  sent  to  it  by'^the  DN-355  and  must 
execute  any  tommands  contained  in  the  message.  Additionally,  the  remote  computer, 
through  the  use  of  Message  Media  Codes  (MMC) ,  must  acknowledge  the  messages  sent 
from  NACE.  NACE  usually  with  send/receive  all  messages  through  the  use  of  write/' 
read,  courtesy  call  driven  sequence.  The  DN-355  will  then  pass  the  message  from 
NACE  to  the  remote  computer.  Upon  receipt  of  the  message  from  NACE,  the  remote 
computer  sends  an  ACK  to  the  DN-355  to  let  the  DN-355  know  that  it  has  received  it. 
The  DN-355  will  then  send  to  the  remote  computer  a  transmit  message  (clear  to  send). 
The  remote  computer  can  then  send, 'receive  message  data.  The  DN-355  expects  a 
response  every  seven  seconds  from  the  remote  computer  (to  remain  in  the  active  mode). 
If  the  remote  computer  has  no  data  to  send,  the  remote  computer  may  either  send  a 
No-Data  message  or  a  Disconnect  message. 

3 . 2  Initiation  Procedures 

In  order  to  receive  from  or  transmit  message  data  to  NACE,  the  DN-355  must  be 
alerted  to  the  remote  computer  wishes  to  sign-on.  Input  is  initiated  by  the 
remote  computer  by  a  SELECT  message.  This  message  may  or  may  not  have  the  defined 
auxiliary  field  (see  paragraph  2. 2. 4.1).  The  SELECT  accomplishes  two  pvirposes; 


a.  The  DN-355  is  made  aware  that  the  remote  computer  is  ready  to  enter  the 
Active  mode  of  operation. 

b.  With  the  auxiliary  field  defined,  the  DN-355  is  told  what  format  in 
which  the  remote  computer  expects  to  receive/transmit  its  message  data. 

3.2.1  SELECT  Format.  The  format  of  the  SELECT  command  with  and  without  the  define-.' 
auxiliary  field,  is  depicted  in  paragraph  2. 2. 4. 2. 

3.2. 1.1  SELECT  Acknowledgement.  The  DN-355  on  receipt  of  the  SELECT  command,  will 
place  the  remote  computer  line  in  the  Active  mode  and  transmit  an  ACK  in  the 
following  format: 

SYN,  SYN,  SYN,  SYN ,  SOH ,  FC ,  SC,  AC,  OC ,  IC,  STX,  ETX,  BCC 

where,  SYN  -  026 
SOH  -  001 
FC  -  110 
SC  -  101  or  102 
AC  -  100 
OC  -  102 
IC  -  100 
STX  -  002 
ETX  -  103 


BCC  - 


Exclusive  OR  of  all  characters  following  the  SOH  up  to 
and  including  the  ETX. 


3.2.2  Log-On  Procedure.  Upon  receipt  of  the  ACK  from  the  DN'-355,  the  remote 
computer  transmits  the  log-on  identification  as  follows: 

SYN,  SYN,  SYN,  SiO,’ ,  SOH ,  FC,  SC,  AC,  OC .  IC,  STX ,  H,  S^SLOGXXUSERIDSPASSWORD , 
22Z,  RS,  ETX,  3CC 

where,  FC  -  104 
OC  -  100 
H  -  1 10 

XX  -  Terminal  Identification  Code  Assigned  ^ 

USERIDSPASSVORD  -  Security  USERIDS  Password  Assigned.  The  XX  and 
USERIDSPASSWORD  are  ASCII  equivalents. 

RC  -  026 

3. 2. 2.1  Log-On  Verification.  If  the  Terminal  ID  and-'or  USERIDSPASSWORD  was 
incorrect,  the  DN-355  will  transmit  a  line  disconnect  message.  Upon  verification 
of  the  Terminal  Identification  and  USERIDSPASSWORD,  the  DN-355  will  -ransmit  an 
ACK  in  the  following  format: 

SYN,  SYN,  SYN,  SYN,  SOH,  FC ,  SC,  AC,  OC ,  IC,  STX,  ETX,  BCC 

where,  FC  =  102,  and  all  other  character  configuration  is  the  same  as 
other  examples. 

3.2.3  Direct  Access  Mode.  When  the  remote  computer  receives  the  ACK  from  the 
DN-355  in  response  to  its  log-on,  it  is  then  necessary  to  inform  the  DN-355  that 
it  wishes  to  be  connected  to  NACE  in  the  DAC  mode. 

This  is  accomplished  by  issuing  the  following  command: 

SYN,  SYN,  SYN,  SYN,  SOH,  FC ,  SC,  AC,  OC,  IC,  STX,  H,  $*$DACNACE-U ,  RS , 

EXT,  BCC 

where,  FC  =•  104 
OC  =  IOC 
H  =  110 

$*$DACNACE-U  is  the  octal  equivalent. 

RS  =  036 

3. 2. 3.1  DAC  Acknowledgement.  When  the  DN-355  receives  this  command  from  the 
remote  computer,  the  DN-355  will  pass  on  to  NACE  the  Terminal  Identification  of 
the  remote  computer  to  NACE.  If  NACE  is  incorrectly  spelled  or  not  in  core,  the 
DN-355  will  transmit  to  the  remote  computer  the  message  "XXXXNOT  KNOWN".  If  the 
Terminal  Identification  is  not  known  to  NACE,  the  line  will  not  be  connected.  If 
the  DAC  command  was  issued  incorrectly,  the  remote  computer  will  have  to  begin 
again  at  the  SELECT  command.  If  the  DAC  command  was  submitted  correctly  and  the 
terminal  code  was  known  to  NACE,  the  DN-355  will  transmit  an  ACK  with  message 
data.  This  message  data  will  include  the  security  classification  of  the  remote 
computer  and  the  data.  The  size  of  this  message  is  25  words  or  100  characters  in 
the  following  format: 

SYN,  SYN,  SYN,  SYN,  FC ,  SC,  AC,  OC ,  IC ,  STX,  Message  data,  ETX,  BCC 

where,  FC  -  115 
OC  -  100 
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3. 2. 3. 2  Remote  Computer  Acknowledgement.  When  the  remote  computer  receives 
this  message  from  the  DN-355,  the  remote  computer  must  (as  always)  acknowledge 
the  receipt  of  it  in  the  following  format: 

SYN,  SYN,  SYN,  SYN ,  SOH,  FC ,  SC,  AC,  OC,  IC,  SIX,  ETX,  BCC 

Where,  FC  -  104  for  ACK,  114  for  NAK 

W’hen  the  DN-355  receives  this  ACK  from  the  remote  computer,  TiACE  is  effectively 

in  control  and  the  remote  computer  will  respond  only  to  requests  from  NACE ;  but 
the  remote  computer  must  acknowledge  the  receipt  of  all  messages  from  the  DN-355 
and  expect  an  ACK  if  transmitting  message  data. 

3.2.4  Ready  from  NACE.  When  the  security  message  is  ACK'ed  by  the  remote 
computer,  NACE  will  issue  a  Ready  message  (FG)  in  the  following  format: 

SYN,  SYN,  SYN,  SYN,  SOH,  FC,  SC,  AC,  OC ,  IC,  SIX,  FG  ,  ETX,  BCC 

where,  FC  =  115 
OC  =  100 

FG  =  MMC  indicating  ready 

The  receipt  of  the  FG  must  be  ACK'ed  in  the  same  format  as  in  paragraph  3. 2. 3. 2. 
When  the  DN-355  receives  this  ACK,  it  will  return  the  ACK  (with  the  same  sequence 
code).  The  return  of  the  ACK  from  the  DN-355  is  a  "clear  to  send"  indication. 

The  remote  computer  must  either  transmit  message  data  or  transmit  a  No  Data  (FI) 
message  to  NACE  to  complete  its  write/read  sequence  from  the  FG  that  was  sent. 

The  format  of  the  NO  Data  message  is  as  follows: 

SYN,SYN,SYN,SYN,FC,SC,AC,OC,IC,STX,FI,NULL,RS,ETX,BCC 

where,  FC  =  315 
OC  =  100 
NULL  =  100 
RS  =  036 

NACE  will  ACK  the  receipt  of  the  No  Data  message  with  another  write/read  sequence 
with  no  MMC.  This  completes  the  initiation  sequence  required  by  the  RCI/DAC 
interface . 


3.3  Message  Transmission  to  NACE. 


Because  NACE  is  providing  message  routing  service  to  other  users  concurrently, 
it  cannot  dedicate  buffers  to  any  one  user  source.  NACE  uses  a  buffer  management 
routine  that  will  allocate  buffers  among  the  active  users.  Therefore,  before 
transmitting  data  to  NACE,  the  remote  computer  must  transmit  a  No  Buffer,  or 
No  Data  MMC.  NACE,  upon  receipt  of  these  commands,  will  attempt  to  find  a  buffer 
that  is  free  for  use.  If  none  can  be  found,  NACE  will  issue  a  wait  MMC.  If  one 
is  found,  NACE  will  respond  with  a  write/read  command  for  the  data.  NACE  must  for- 
ware  (route)  the  messages  that  it  receives  to  the  processors'  message  queues  that 
are  to  receive  them.  However,  there  are  times  a  message  cannot  be  identified  for 
routing.  When  this  occurs,  NACE  will  NAK  the  message,  but  will  accept  the  message 
in  its  entirety  for  possible  correction  through  other  NACE  facilities.  The  remote 
computer,  if  it  is  acting  as  a  message  concentrator,  must  also  be  prepared  to 
preempt  transmission  of  a  current  message  to  transmit  one  of  a  higher  message 


precedence.  This  is  accomplished  by  transmitting  a  "cancel"  MMC  to  NACE .  NACE 
will  then  "forget"  the  current  message,  and  transmit  an  ACK  to  the  remote  computer. 
The  remote  computer  should  then  relink  the  current  message  for  later  transmission, 
and  transmit  the  one  of  higher  message  precedence. 

3.3.1  Ready  Message.  To  initially  request  a  buffer  from  NACE,  the  remote  computer 
transmits  a  "Ready"  MMC  to  complete  the  write/read  of  NACE.  The  format  of  the 
Ready  message  is  as  follows: 

SYN , SYN , SYN , SYN , SOH , FC , SC , AC ,0C , IC , STX , FG ,  DC  ,  5 ,RS , ETX  ,^CC 

Where,  FC  =  115 
OC  =  100 
FG  =  Ready 

DC  =  Data  compression  character  037 
5  =  065 
RS  =  036 

When  NACE  receives  this  Ready  message  from  the  remote  computer,  NACE  will  respond 
by  transmitting  a  write/read  (write  0  words/read  large)  sequence  with  no  MMC. 

The  format  of  this  message  is: 

SYN , SYN , SYN , SYN  ,  SOH , FC , SC , AC , OC , IC , STX ,ETX , BCC 

FC  =  100 

3.3.2  Message  Data  Transmission.  After  receiving  the  ACK  from  NACE  in  paragraph 
3.3.1,  the  remote  computer  may  begin  transmitting  message  data  in  the  following 
format ; 

SYN , SYN , SYN , SYN , SOH , FC , SC , C , OC , IC , STX ,MMC , - RS ,MMC , — 

- RS,MMC - RS, ETX, BCC 

where,  FC  =  115 
OC  =  100 
RS  -  036 

MMC  =  will  depend  upon  the  type  of  data  message  being  transmitted. 

Assuming  there  were  no  line  errors,  NACE  will  ACK  or  NAK  the  message  (depending 
on  whether  the  message  was  identified  or  not)  with  the  next  write/read  sequence. 

3.3.3  No  Buffer  Available  (Wait).  When  this  message  is  received  by  the  remote 
computer,  it  indicates  that  NACE  does  not  have  any  available  buffer.  NACE  will 
transmit  this  message  as  a  Write  three  words/Read  Small.  The  format  of  this 
message  is: 

SYN , SYN , SYN , SYN , SOH , FC , SC , AC , OC , IC , STX , FE  , RS  ,  ETX  ,  BCC 

where,  FC  =  115 
OC  =  100 

The  remote  computer  must  transmit  an  ACK  to  the  DN-355  to  complete  the  write/ 
read  sequence  of  NACE  and  let  its  timer  run-out.  The  remote  computer  may  restart 
its  transmission  by  transmitting  thr  Ready  message  in  paragraph  3.3.1.  The 
format  for  this  ACK  is  the  same  as  paragraph  3. 2. 3. 2.  The  DN-355  will  return  the 


ACK  (same  sequence  code)  to  the  remote  computer. 

3.3.4  Cancel  Messages.  It  may  become  necessary  to  stop  transmission  of  message 
data  because  of  preemption  by  another  message  with  a  higher  routing  precedence 
or  after  encountering  too  many  line  errors.  The  format  for  this  message  is  as 

f o 1  lows : 

SYN , SYN , S YN , SYN , SOH , FC , SC , AC , OC , IC , STX , FF , NULL , RS , ETX , BCC 

r’ 

where,  FC  -  315 
OC  =  100 

FF  -  MMC  denoting  cancel 
NULL  =  100 
RS  =  036 

NACE ,  upon  receipt  of  the  cancel  message,  will  determine  whether  it  must  purge 
the  portion  of  the  message  that  was  already  received  or  "forget"  that  it  ever 
received  chat  portion.  In  either  case,  NACE  will  ACK  the  receipt  of  the  cancel. 
The  remote  computer  must  relink  the  message  for  later  transmission,  time  out,  and 
then  transmit  a  Ready  message  for  Che  data  message  with  the  higher  routing  pre¬ 
cedence.  In  the  case  of  multiple  errors,  the  remote  computer  must  time  out  and 
either  transmit  a  No  Data  or  Disconnect  depending  on  Che  condition  of  the  line. 

3.3.5  Status  Request.  The  remote  computer,  because  of  the  response  made  of  the 
RCI/DAC,  never  requests  Che  operational  status  of  NACE,  but  always  replies  to  the 
Status  request  from  NACE.  The  format  of  the  Status  request  from  NACE  is: 

SYN,SYN,SYN,SYN,FC,SC,AC,OC,IC,STX,FAddeee  ,RS,ETX,BCC 

where,  FC  =  102 
OC  =  104 

FA  =  MMC  denotes  Status  request 
dd  =  Terminal  identification 

eee  =  Message  communication  if  remort  computer  is  a  message 
Concentrator 

When  the  remote  computer  receives  this  message,  it  must  determine  the  condition 
of  its  line  and  transmit  a  response  in  the  following  format. 

SYN,SYN,SYN,SYN,SOH,FC,SC,AC,OC,IC,STX,FBddeeef ,RS,ETX,BCC 

where,  FC  =  115 
OC  =  100 

FB  =  MMC  denoting  Status  information 
dd  =  Terminal  identification 
eee  =  Communication  line  of  message  concentrator 
f  =  U  for  Up,  D  for  Down  and  N  for  Not  Configured 
RC  =  036 

3 .4  Line  Disconnect 

This  message  is  of  two  types,  a  Ready  for  Disconnect  and  a  Disconnect,  and  each 
may  be  sent  by  the  remote  computer,  the  DN-355  or  NACE. 


3.4.1  Remote  Computer  Disconnect:.  When  the  remote  computer  determines  that 

it  has  no  more  data  messages  to  send,  it  transmits  a  Disconnect  message  to  NACE 
in  the  following  format: 

SYN,SYN,SYN,SYN,FC,SC,AC,OC,IC,FH,NULL,RS,ETX,BCC 

where,  FC  =  115 
OC  =  100 

FH  =  MMC  denoting  Disconnect  ^ 

3. 4. 1.1  NACE  Response  to  Disconnect.  NACE,  upon  receipt  of  the  Disconnect,  will 
assure  that,  if  a  message  was  in  progress  when  the  Disconnect  was  received,  it 
will  be  purged  and  then  a  Disconnect  will  be  transmitted  to  the  DN-355.  The 
format  of  this  message  is  the  same  as  paragraph  3.4.3. 

3. 4. 1.2  DN-355  Response  to  Disconnect.  The  DN-355,  upon  receiving  the  Disconnect 
message  from  NACE,  will  transmit  the  Disconnect  message  to  the  remote  computer  in 
the  format  of: 

3YN,SYN,SYN,SYN,S0H,FC,SC,AC,0C,IC,STX,NLINE  DISCONNECTED — CP ,RS ,ETX ,BCC 

where,  FC  =  104 
OC  =  100 

This  message  must  be  acknowledged  by  the  remote  computer  in  the  following  format: 

SYN , SYN , SYN , SYN , FC , SC , AC ,0C , IC , STX ,ETX , BCC 

where,  FC  =  104 
OC  =  100 

When  the  DN-355  receives  this  ACK,  it  will  remove  the  terminal  ID  from  its  DAC 
terminal  table  and  transmit  another  Disconnect  in  the  following  format: 

SYN , SYN , SYN , SYN , FC , SC , AC , OC , IC , STX , ETX , BCC 

where,  FC  =  102 
OC  =  104 

The  remote  computer  will  then  transmit  its  final  ACK  in  the  format  of: 

S'YN  ,  SYN  ,  SYN  ,  SYN  , FC  ,  SC  ,  AC  , OC  ,  IC  ,  STX , BCC 

where,  FC  =  102 
OC  =  104 

3. 4. 1.3  Disconnect  Immediately.  When  this  message  is  received  by  the  DN-355, 

it  will  Disconnect  the  line  without  responding  (ACK)  to  the  message.  Any  messages 
(input  or  output)  destined  for  the  remote  computer  will  be  destroyed  and  NACE 
will  be  notified.  the  format  is: 

SYN  ,  SYN , SYN , SYN , FC , SC , AC , OC , IC , STX , ETX , BCC 

where,  FC  =  102 
OC  =  104 
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3.4.2  Disconnect  from  the  DN-355.  The  DN-355  will  transmit  a  Disconnect  when 
the  line  is  too  bad  (hardware  problems)  to  properly  handle  a  Ready  for  Disconnect. 
Upon  receipt  of  this  message,  the  remote  computer  disconnects  immediately  without 
responding.  The  format  of  this  message  is: 

SYN,SYN,SYN,SYN,SOH,FC,SC,AC,OC,IC,STX,ETX,BCC 

where,  FC  =  102 

OC  =  104  , 

3.4.3  Ready  for  Disconnect  from  NACE.  When  NACE  is  at  an  End-of-Job  condition, 
it  will  determine  if  there  is  a  message  in  progress,  if  so,  NACE  will  allow  the 
message  in  progress  to  be  completed,  before  transmitting  a  "Ready  for  Disconnect". 
The  format  of  this  message  is  as  follows: 

SYN , SYN , SYN , SYN , SOH , FC , SC , AC , OC , IC , STX , FH , ETX , BCC 

where,  FC  =  102 
OC  =  100 

FH  =  Ready  for  Disconnect 

3. 4. 3.1  Remote  Computer  Response.  When  the  Ready  for  Disconnect  message  is 
received,  the  remote  computer  should  relink  all  remaining  messages  for  later 
transmission  and  ACK  the  receipt  of  the  Disconnect  to  the  DN-355,  with  the 
following  message: 

SYN, SYN, SYN, SYN, SOH, FC, SC, AC, 0C,IC, STX, ETX, BCC 

where,  FC  =  104 
OC  =  100 

The  DN-355  will  respond  to  the  ACK  with  the  following  Clear  to  Send  message: 

SYN, SYN, SYN, SYN, SOH, FC, AC, 0C,IC, STX, ETX, BCC 

where,  FC  =  110 
OC  =  102 

The  remote  computer  must  then  ACK  the  receipt  of  the  FH  to  NACE  with  the  following 
message : 

SYN,SYN,SYN,SYN,SOH,FC,AC,OC,IC,STX,FC,NULL,RS,ETX,BCC 

where,  FC  =  115 
OC  =  100 

FC  =  denotes  ACK 

NACE,  upon  the  receipt  of  this  ACK,  will-send  to  the  DN-355  a  Disconnect  message. 
The  DN-355  will  then  transmit  a  Ready  for  Disconnect  in  the  following  format: 

SYN, SYN, SYN, SYN, SOH, FC, SC, AC, IC, STX, N  LINE  DISCONNECTED  — CP  ,RS  ,ETX  ,BCC 

The  message  must  be  ACKed  by  the  remote  computer  with  the  following  message: 

SYN , SYN , S YN , SYN , SOH , FC , SC , AC , OC , IC , STX , ETX , BCC 


where,  FC  =  104 


[•It] 


The  DN-355  will  then  accomplish  the  Disconnect  with  the  final  message: 


SYN,SYN  ,SYh’,SYN,SOH,FC,SC,AC,OC,IC,STX,ETX,BCC 

where,  FC  =  102 
OC  =  104 


3. 4. 3. 2  Disconnect  Immediately  from  NACE.  If  one  of  the  NACE  modules  aborts, 
NACE  will  attempt  to  save  as  much  of  its  operating  environment  as  possible,  and 
therefore,  has  little  time  to  perform  the  nicety  of  the  formal  RCI/DAC  interface. 
NACE  will  immediately  disconnect  the  line  without  notifyin^the  remote  computer 
and  expects  no  response  as  a  result  of  the  disconnect. 


3.5  Operational  Deviations 


The  RCI/DAC  interface,  with  its  user  defined  format,  was  designed  to  interface 
with  the  NMCS  AUTODIN  Terminal  Subsystem  (NATS).  However,  other  remote  computers 
can  (and  have  been)  also  be  configured  to  operate  within  the  interface  without 
adhering  to  all  formal  rigidity  required  by  the  RCI/DAC  interface.  An  agreement 
must  be  reached  between  the  users  of  the  remote  computers  and  the  NACE  support 
staff  as  to  the  format  and  volume  of  the  message  data  that  is  to  be  transmitted/ 
received.  The  format  and  volume  must  satisfy  the  basic  requirements  of  the  RCI/ 

DAC  and  DN-355  interface.  The  DN-355  must  first  of  all  be  satisfied  as  to  the 
SELECT  and  DAC  that  must  be  issued  in  order  to  be  connected  to  NACE.  Once  connected 
to  NACE,  the  remote  computer  must  be  prepared  to  either  send  or  receive  message 
data,  or  to  send  a  wait  command  to  prevent  timing  out.  The  minimum  MMC  that  can  be 
used  are:  Ready,  No  Data,  No  Buffer,  Disconnect  and  Acknowledgements  (positive  or 
negative).  NACE  can  be  modified  to  handle  a  variety  of  messages  even  though  they  do 
not  conform  to  the  format  of  the  current  NACE  users. 
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The  following  is  a  detailed  description  of  the  formats  of  each  message  as 
viewed  by  the  NATS  and  NACE  and  a  description  of  the  control  information 
necessary  to  communicate  with  the  DN355  and  the  H6000- 

As  a  prelude,  a  description  of  the  NATS/NACE  subconvention  specifications 
is  necessary.  The  following  paragraphs  define  the  specification  for  the 
NATS/NACE  subconvention. 

1.  There  will  be  a  logical  and/or  physical  link  for  traffic  from  NATS 
to  NACE.  This  line  will  handle  all  data,  control  sequences  and  protocol 
required  to  facilitate  the  transfer  of  data  from  NATS  ^  NACE. 

2.  There  will  be  a  logical  and/or  physical  link  for  traffic  from  NACE 
to  NATS.  This  link  will  handle  all  data,  control  sequences,  and  protocol 
required  to  facilitate  the  transfer  of  data  from  NACE  NATS. 

3.  Each  link  will  appear  as  a  separate  port  to  both  NACE  and  NATS  and 
will  require  no  cross  talk  between  ports  for  operation. 

4.  Basic  security  features  are  being  developed  by  the  Government  for 
the  NATS/NACE  subconvention.  The  security  features  are: 

a.  RCI/DAC  log-on  and  access  level  check. 

b.  Security  code  labeling  of  output  (to  NATS)  adequate  to  allow 
for  security  caveat  development  at  the  final  destination  output  device. 

These  security  features  are  projected  to  be  available  in  a  subsequent  version 
of  WWSR6.0. 

5.  To  insure  positive  control  of  the  link,  log  on  to  a  direct  access 
program  will  be  a  log-on  •^ith  no  wait.  If  DAC  program  has  not  issued  a 
"CONNECT"  MME  GEROUT  for  the  terminal,  a  message  "DAC"  NOT  KNOWN  will  be 
transmitted . 

6.  NACE  will  set  status  bit  to  place  355  in  listen  mode  to  NATS 
terminal  for  duration  of  connect. 
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7.  Messages  cransmi teed  across  the  link,  either  way,  will  confirm  to 
the  following: 

a.  Messages  will  be  broken  down  into  message  segments  with  each 
segment  containing  a  maximum  16  lineblocks  of  80  data  characters  each.  Each 
message  segment  will  contain  complete  lineblocks.  Compression  of  data  and 
truncation  of  trailing  blanks  will  be  allowed. 

b.  Each  lineblock  within  a  segment  will  be  preceded  by  a  media  code 
character  and  will  be  followed  by  a  record  separator  -  (Octal  36  -  Hexidecimal  9E). 
The  media  code  character  will  contain  information  about  the  link  block  that 
follows.  The  following  media  codes  (NOTE  -  ALL  CODES  ARE  IN  ASCII)  will  be 
used : 


MEDIA 

OCT 

CODE 

HEX 

CHARACTER 

ASCII 

DESCRIPTION 

1 

101 

Cl 

(A) 

*  Single  card  message 

2 

102 

C2 

(B) 

*  Header 

3 

103 

43 

C 

**  Text  -  Card  Image 

4 

104 

C4 

D 

**  Trailer  -  End  of  Message 

5 

105 

45 

E 

***  Text  -  Variable  Length 

6 

106 

46 

F 

****  Control  Information 

7 

107 

C7 

G 

Operator  Message 

*  NOTE:  MEDIA  CODES  (A)  AND  (B)  WILL  BE  FOLLOWED  BY  THE  AUTODIN  SEL  CHARACTER 
(FRAMING  CHARACTER  TWO). 

**  NOTE:  MEDIA  CODES  (C)  AND  (D)  WILL  BE  FOLLOWED  BY  THE  SECURITY  CLASSIFICATION 
***  NOTE:  A  PROVISION  HAS  BEEN  MADE  WITHIN  THE  SUBCONVENTION  FOR  VARIABLE  LENGTH 
BUT  THE  NACE  PACKAGE  CANNOT  HANDLE  IT. 

****  NOTE:  MEDIA  CODE  (F)  WILL  BE  FOLLOWED  BY  ONE  OF  THE  FOLLOWING  CHARACTERS  TO 
DESCRIBE  THE  CONTROL  FUNCTION 
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OCT 


HEX 


ASCII 


DESCRIPTION 


•**  ^ 

1 

101 

Cl 

A 

•* 

2 

102 

C2 

B 

3 

103 

43 

C 

v*  • 

4 

104 

C4 

D 

•i* 

5 

105 

45 

E 

n 

•K  . 

..  •  . 

uyA 

6 

106 

46 

F 

7 

107 

C7 

G 

8 

110 

C8 

H 

9 

111 

49 

1 

1 

be  in 

the 

• 

A  status  request  will 

im 

F 

A  dd  eee 

F 

=  Control 

Information 

A 

=  Status 

Request 

r 

k  *  •  * 

a 

dd 

=  Generic 

Device 

Type 

.•\  . 


[  V.  >' 

^,rjj 


•3 


v:'. 

II 

t:--.’ 


1. 


Status  Request 


'Status  Information 
Super  ACK 


Super  NAK  -  may  not  be  sent  to 
core  only  systems 


WAIT 

Cancel  Current  Message 
Pseudo  Break 
Terminate 


No  Data  (sent  by  transmitter  only 
for  handshaking) 


NOTE:  COMMUNICATION  GENERIC  DEVICE  TYPES  TO  BE  DEVELOPED, 

eee  =  Unit  Number 

2 

A  status  request  will  be  answered  in  the  following  format: 
F  B  dd  ee  f 
F  =  Control  Information 
B  =  Status  Information 
dd  eee  -  Echo  of  Status  Request 
f  =  Status 
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MESSAGE  FORMATS 

This  is  a  description  of  the  message  formats  and  the  DN355  control  information 
necessary  to  pass  these  massages.  The  complete  DN355  protocol  will  not  be 
described  in  this  paper.  A  supplemental  will  be  added  in  the  future  to  describe 
the  entire  DN355  protocol  (i.e.,  NACK  procedures,  DN355  titpe-out  procedures, 
etc.)  for  the  benefit  of  the  remote  computer. 

The  following  is  a  description  of  the  control  information  block  necessary  to 
effect  communications  with  the  DN355  and  H6000. 


CONTROL  INFORMATION - CONTROL  RECORD  OR  DATA 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

lla/llb  12 

s 

S  S 

S 

S 

F 

S 

A 

0 

I 

A 

S 

Data  (Maximum  324 

ch . 

or  16  LBs)  ETX/ETB  B 

Y 

Y  Y 

Y 

0 

C 

C 

C 

c 

C 

U 

T 

C 

N 

N  N 

N 

H 

X 

X 

C 

End  of  Block 

Contro 1 

Information 

I  • 

SYN 

- 

This 

is 

the  SYNchronization 

character  and  is  a 

HEX' 

'16'  (OCT  '026'). 

This  character  remains  constant. 

2.  SOH  -  This  is  the  Start  of  Header  character  and  is  HEX  '01'  (OCT  '001'). 

This  character  remains  constant. 

3.  FC  -  This  is  the  Format  Code  character  which  varies  with  tye  type  of  message 
to  be  passed.  The  four  types  are  Info,  Special  Control  Record,  Data  and  Service. 

4.  SC  -  This  is  the  Sequence  Code  character  which  alternates  between  a  HEX  'Cl" 
(OCT  '301')  and  a  HEX  ' C2 ’  (OCT  '302'). 

5.  AC  -  This  is  the  Address  Code  character  which  is  not  used  but  must  be  in  the 
control  information.  It  is  a  HEX  '40'  (OCT  '100').  This  character  remains 
constant . 

6.  OC  -  This  is  the  Operation  Code  character  and  is  used  for  ACKnowledgements  and 
NonACKnowledgements .  ACKnowledgements  are  recorded  as  HEX  '40'  (OCT  '100')  and 
NonACKnowledgements  can  very  dependent  upon  existing  conditions. 

7.  IC  -  This  is  the  Identification  Code  character  and  is  a  HEX  '40'  (OCT  '100'). 
This  character  remains  constant. 

8.  AUX  -  This  is  the  Auxiliary  fields  code  character  and  is  normally  present  onJv 
in  a  SELECT  SERVICE  message.  When  used,  it  is  a  HEX  'C7"  (OCT  '307'). 
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Q.  STX  -  This  is  che  Start  of  Text  character  and  is  a  HEX  '02'  (OCT  '002'). 

This  character  remains  constant. 

10.  DATA  -  This  is  the  D.ATA  or  control  record  field.  Further  discussion  of 
Data  formats  will  be  discussed  in  che  respeccion  portions  of  this  paper,  Transmi 
or  Receive. 

11a.  EXT  -  This  is  the  End  of  Text  character  and  is  a  HEX  '83'  (OCT  '203'). 

lib.  ETB  -  This  is  the  End  of  Transmission  Block  character  and  is  a  HEX  '97' 
(OCT  '227'). 

12-  BCC  -  This  is  the  Block  Check  Character  and  is  a  cumulative  exclusive  OR 
opera*'ion  with  each  character  following  the  SOH  and  up  to  and  including  the 
ETB/ETX.  The  BCC  must  be  odd  parity. 

All  information  must  be  odd-parity  and  all  but  SYN,  SOH,  STX,  ETB/ETX,  and 
BCC  are  valid  ASCII  characters.  The  following  translations  are  provided  for 
the  ASCII  characters  used  in  the  control  information. 

HEX  OCT  ASCII 


The  following  messages  are  the  messages  to  be  expected  on  Transmit  and  Receive. 
They  will  be  referenced  by  message  number  in  the  expansion  of  the  narrative 
descriptions  of  the  Transmit  and  Receive  sections  of  this  paper. 

MESSAGES 


0 

c 

I 

C 

A 

U 

X 

B 

@ 

G 

^Sequence  Code  must  always  be  initialized  as  a  "3 


S  S  S  S  F  S[A  Ofl 
YYYOCCCCC 
H 


SS  SSFSAOI 
YY  YOCCCCC 


H  B  t  B  @ 


10.  XX*R 
S 


■XX  represents  the  NATS/NACE  subconvention  control  characters. 
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D  A  T  A  R 
S 


XXDATARXX 

S 


G 

N 

A  T 

S 

D 

I  S 

C 

0  N 

N 

E  C 

T 

S 

S 

S 

S 

S 

F 

S 

A 

0 

I 

S 

E 

B 

Y 

Y 

Y 

Y 

0 

C 

C 

C 

C 

C 

T 

t' 

C 

N 

N 

N 

N' 

H 

X 

X 

C 

D 

B 

© 

© 

© 

N  LINE  DISCONNECTED  XXX 

XXX  IS  VARIABLE 
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.■5 _ _ 'jvAjl. 


>?DEND!X  G:  WWfCCS  RTOS 


line  discipline 

FOR 

AUTODIN  INTERFACE 


DCT  9000  -  DN  355 


CONTENTS 


MESSAGE  TYPES 

FORMATS 

START  SEQUENCE 

THE  BREAK  MESSAGE 

WAIT  SEQUENCE 
TERMINATE  SEQUENCE 

character  definitions  and 


BINARY  equivalents 


A.  MESSAGE  TYPES 

Information  -  used  for  transferring  AUTODIN  message  data  and 
sending  acks/naks. 

2.  Special  Control  Record  -  used  for  sign  on,  $*$id;  break  message 
052;  or  S*SDAC,  Direct  Access  Request- 

3.  Service  -  used  to  initiate  or  terminate  communications,  send 
instruction  or  operation  information  to  the  other  computer,  and  ack/nak 
service  messages  from  the  other  computer. 
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3.  FORMATS 

General  Inf ornac ion : 

a.  A  transmission  block  is  made  up  of  a  maximum  of  253  characters 
including  synchron icat ion  characters.  .An  ack 'nak  for  the  previous  block 
transmitted  is  contained  within  the  next  block  to  be  transmitted.  Data  is 
exchanged  using  the  .ASCII  character  set  with  odd  parity. 

b.  Data  format  within  3 24.-character  test. 

(1)  Data  sice  will  be  three  80-char  records  for  a  total  maximum 
of  240  characters  between  STX  and  ET3,'ETX  characters. 

(2)  "ETB"  is  used  to  end  each  of  the  first  four  240-character  blocks. 

(3)  "ETX"  is  used  to  end  the  fifth  or  the  last  240-char  block.  In 
either  case,  no  more  data  blocks  should  be  sent  until  after  a  "TRA.N’SMIT  DATA" 
message  is  received  from  the  355. 

c.  The  ACK;'XAK  for  an  "output"  transmission  block  is  located  in  the 
Operations  code, type  character  of  the  next  "input"  transmission  block  received. 
This  op/type  code  has  the  following  bit  pattern: 


BIT  7 

6  5  4 

3  2  1 

USE  1 

ACK/NAK 

OP  CODE 

An  ACK  is  denoted  by  bits  4,  5,  and  6  being  turned  off  and  a  NAK  is  denoted 
by  bit  4  being  on  and  bits  5  and  6  being  off. 

2.  The  format  for  all  three  message  types  is  basically  the  same: 

SYN,  SYN,  SYN,  SYN ,  SOH ,  FC,  SC,  AC,  TYPE/,  STX,  CONTROL  RECORD  TEXT,  ETB, 


ETX,  BCC. 


The  four  sync  characters,  the  start  of  header  (!SOH),  address  code.  (AC), 
Identification  code  (IC),  start  of  test  (STX) ,  and  end  of  transmission  block 
(ETB).end  of  text  (ETX)  character  are  constant  and  are  always  present.  The  format 
code  (FC)  character  identifies  the  type  of  message;  info,  special  control 
record,  or  service.  The  sequence  code  (SC)  alternates  between  "A"  and  "3"  with 
each  block  transmitted  with  the  SC  reverting  to  "A"  on  the  start  sequence.  The 
type /operat ion  code  identifies  a  type  of  message  within  each  of  the  three  major 
types;  e.g.,  a  "select"  service  message,  a  "transmit  data"  information  message, 
etc.  The  block  check  character  (BCC)  is  a  cumulative  exclusive  OR  operation 
with  each  character  following  the  SOH  and  up  to  and  including  the  ETB/ETX. 

The  BCC  must  also  have  odd  parity. 

3.  Information  Message 

a.  To  the  DN355: 

(1)  To  transmit  data  and  ACK  the  last  DN355  message:  SYN ,  SYN' ,  SYN, 

SYN,  SOH,  M.  A,  (§,  @,  ®,  STX,  TEXT,  ETB ,  BCC 
3  ETX 

Use  alternate  sequence  code. 

(2)  To  transmit  data  and  NAK,  the  last  DN355  message:  SYN,  SYN,  SYN, 

SYN,  SOH,  M,  A,  @,  H,  ©,  STX,  SAME  TEXT,  ETB,  BCC 
B  ETX 

Use  the  same  sequence  code. 

(3)  To  transmit  data  in  answer  to  a  NAK  from  the  DN355:  SYN,  SYN,  SYN, 

SYN,  SOH,  M,  A,  S,  @,  STX,  SA.ME  TEXT,  ETB,  BCC 
B  ETX 

Use  same  sequence  code. 

b.  To  send  a  "WAIT"  message  to  the  DN355: 

(1)  To  transmit  a  wait  and  ACK  the  last  DN355  message:  SYN,  SYN,  SYN, 

SYN,  SOH,  H,  A,  @,  D,  STX,  ETX,  BCC 
M  B 

Data  contained  between  STX  and  ETX  will  not  be  recognized  by  the  355.  Use 
same  sequence  code. 


(2)  The  Las;:  355  message  can  be  N'ACKED,  but  when  the  355  receives 
a  aAIT,  it  retransmits  the  last  message  anyway. 

(3)  The  remote  computer  does  not  send  "TRANSMIT  DATA"  messages, 
c.  Data  from  the  DN355: 

(1)  Receiving  data  with  an  ACK  of  last  9000  message:  SYN ,  SYN ,  SYN , 

SYN,  SOH,  M,  A,  ©,  S,  ©,  ©,  STX ,  TEXT,  ETB ,  BCC 
B  ETX 

Alternate  sequence  code  used. 

(2)  Receiving  data  with  a  NAK  of  last  9000  message;  SYN,  SYN,  SYN, 

SYN,  SOH,  M,  A,  ©,  H,  ©,  STX,  SAME  TEXT,  ETB,  BCC 
3  ETX 

Same  sequence  code  used. 

(4)  Receiving  data  NACKED  by  9000  on  previous  transmission: 


SYN, 

SYN,  SYN,  SYN: 

,  SOH, 

-M,  A,  ©, 
3 

@,  ©,  STX,  SAME  TEXT,  ETB,  BCC 

ETX 

Same 

sequence  code 

used . 

d.  "TRANSMIT  DATA"  message  from  DN355: 

(1)  Receiving  TRANSMIT  DATA  message  with  ACK  from  355:  SYN,  SYN,  SYN, 

SYN,  SOH,  H,  A,  @,  B,  @,  STX,  ETX,  BC 
B 

Alternate  sequence  code  used. 

(2)  Receiving  TRANSMIT  DATA  message  with  NAK  from  355:  SYN,  SYN,  SYN, 

SYN,  SOH,  H,  A,  ®,  J,  @,  STX,  ETX,  BC 
B 

Same  sequence  code  used. 

4.  SPECIAL  CONTROL  RECORD  MESSAGE 
a.  To  the  DN  355: 

(1)  To  transmit  break  control  record  and  ACK  last  355  msg:  SYN,  SYN, 

SYN,  SYN,  SOH,  D,  A,  @,  @,  ©,  STX,  H,  1,  RS ,  ETX.  BCC 
B 

6' 


Use  changed  sequence  code. 

(1)  To  cransmic  break  concrol  record  and  NAK  last  355  msg ; 

SVN'.  SYN,  SY:'.',  SYN,  SOH.  D,  a,  S',  H,  J,  SIX,  H,  1,  RS .  ETX .  BCC 

B 

Use  same  sequence  code. 

(3)  To  transmit  an  ID  control  card  and  ACK  last  355  msg: 

SYN,  SYN,  SYN,  SYN,  SOH,  D,  A,  @,  @,  @,  SIX,  H,  $*$  id  USERID 

B 

SPASSWORD,  RS,  ETX,  BCC 
Use  alternate  sequence  code. 

(^)  To  transmit  an  ID  control  card  and  NAK  the  last  355  msg:  SYN, 

SYN,  SYN,  SYN,  SOH,  D,  A,  §,  H,  ®,  STX ,  H,  $*$id  USERIDSPASSWORD ,  RS ,  ETX,  BCC 

B 

Use  same  sequence  code, 

(5)  To  transmit  direct  access  (DAC)  control  record  and  ACK:  SYN,  SYN, 

SYN,  SYN,  SOH,  D,  A,  @,  @,  ©,  STX,  H,  $*$DACFQRTOS ,  RS ,  ETX,  BCC 
B 

Use  alternate  sequence  code. 

(6)  To  transmit  DAC  control  record  and  NAK  last  msg:  SYN,  SYN,  SYN, 

SYN,  SOH,  D,  A,  @,  H,  ©,  STX,  H,  $*$DACFQRTOS ,  RS ,  ETX,  BCC 
B 

Use  same  sequence  code, 
b.  From  the  DN355: 

(1)  Receive  special  control  record  with  ACK  of  last  9000  msg:  SYN, 

SYN,  SYN,  SYN,  SOH,  D,  A,  ©,  @,  @,  STX,  N,  MESSAGE,  RS ,  ETX,  BCC 

B 

Alternate  sequence  code  used. 

(2)  Receive  special  control  record  with  NAK  of  last  9000  msg:  SYN, 

SYN,  SYN,  SYN,  SOH,  D,  A,  ©,  H,  ©,  STX,  N,  MESSAGE,  RS ,  ETX,  BCC 

B 


Same  Sequence  code  used. 


SERVICE  MESSAGE 


3 . 


a.  To  che  DN355: 

(1)  To  transmit:  a  "NO  INSTRUCTION"  message  and  ACK  the  last 

DN355  service  message:  SYN ,  SYN ,  SYN ,  SYN ,  SOU,  B,  A,  'A,  STX ,  ETX,  BCC 

3 


Use  alternate  sequence  code. 

(2)  To  transmit  a  "NO  INSTRUCTION"  message  and  NAK  the  last  DN355 

service  message:  SYN,  SYN,  SYN,  SYN,  SOH ,  B,  A,  ©,  H,  ©  STX,  EXT,  BCC. 

B 


Use  same  sequence  code. 

(3)  To  transmit  a  "SELECT"  message  with  ACK:  SYN,  SYN.  SYN,  SYN, 

SOH,  C,  A,  ©,  B,  ©,  G,  STX,  ETX,  BCC 
B 

Uses  auxiliary  field  to  denote  no  compression,  no  split.  Use  alternate 
sequence  code, 

(L)  To  transmit  a  "SELECT"  message  with  a  NAK:  SYN,  SYN,  SYN,  SYN 

SOH,  C,  A,  ©,  J,  ©,  G,  STX,  ETX.  BCC 
B 

Use  same  sequence  code. 

(5)  To  transmit  a  "READY  FOR  DISCONNECT"  message  with  an  ACK: 

SYN,  SYN,  SYN,  SYN,  SOH,  B,  A,  ©,  D,  ©,  STX,  ETX,  BCC 

B 

Use  alternate  sequence  code, 

(6)  To  transmit  a  "READY  FOR  DISCONNECT"  message  with  a  NAK:  SYN, 

SYN,  SYN,  SYN,  SOH,  B,  A,  ©,  L,  @,  STX,  ETX,  BCC 

B 

Use  Same  sequence  code. 

(7)  To  transmit  a  "DISCONNECT"  message  with  an  ACK:  SYN,  SYN,  SYN 

SYN,  SOH,  B,  A,  ©,  F,  A,  STX,  ETX,  BCC 
B 

Use  alternate  sequence  code. 


b.  From  che  DN  355: 

(1)  TERMINATE,  READY  FOR  DISCONNECT,  and  DISCONNECT  messages 
have  rhe  same  format  used  for  sending  to  the  DN355.  The  "NO  INSTRUCTION"  and 
"NOT  READY  FOR  DISCONNECT"  messages  are  not  sent  by  the  DN355. 

(2)  To  transmit  a  "TERMINATE"  message  with  an  ACK:  SYN ,  SYN , 

SYN,  SYN,  SOH,  B,  A,  ®,  C,  @,  STX,  ETX ,  BCC 
B 

Use  alternate  sequence  code. 

c.  START  SEQUENCE 

(1)  9000  sends  a  "SELECT"  SERVICE  message  to  DN  355. 

Ref  B5a(3) 

(2)  355  sends  a  "TRANSMIT  DATA"  INFO  message  to  9000. 

Ref  B3d(l) 

(3)  9000  sends  an  "I.D."  CONTROL  RECORD  message  to  355. 

Ref  B4a(3) 

(4)  355  sends  "TRANSMIT  DATA"  message  to  9000. 

Ref  B3d(l) 

(5)  9000  sends  "$-*$DAC"  CONTROL  RECORD  to  355. 

Ref  B4a(5) 

(6)  355  sends  "NO  REQUEST"  DATA  INFO  msg  to  9000.  (The  data 

in  this  msg  will  be  ""RDYBK"  to  indicate  no  output  at  this  time  for  9000,  but 
input  will  be  accepted  once  the  9000  sends  a  "BREAK"  message.  DAC-IDLE  mode 
entered . ) 

Ref  B3c(l) 

7.  If  the  9000  does  not  send  a  "BREAK"  message,  it  must  send  a  NO  DATA  "NO 
REQUEST"  message  to  ACK  the  355  message. 

Ref  B3a(l)  with  no  "TEXT". 

The  next  message  it  can  then  expect  from  the  355  is  a  "NO  REQUEST"  DATA 
message  containing  data  from  the  6070  program. 


Re  f  33a( 1 ) 

S.  '■^000  muse  eher.  send  a  NO  DATA,  "NO  REQUEST"  message  co  the  355. 

If  the  9000  sends  a  "BREAK"  message,  (Ref  B4a(l)),  the  next  message  it  can 
expect  is  a  "TRANSMIT  DATA"  INFOR.MATION  message  from  the  355. 

Ref  B3d(l) 

d.  THE  "BRE.AK"  MESSAGE. 

(1)  This  SPECI.AL  CONTROL  message  is  sent  to  the  DS  355  by  the 
DCT  9000.  The  355  does  not  send  this  message. 

(2)  when  the  DCT  9000  has  data  to  transmit  to  the  DN355/H6070,  it 

must  send  a  "BREAK"  message  first.  This  sends  a  bit  in  the  H6070.  When  this 
bit  is  detected  as  being  set,  the  355  will  be  issued  a  command  from  the  6070 
such  that  the  355  will  send  the  9000  a  "TRANSMIT  DATA"  message.  After  all  data 
has  been  transmitted  from  the  9000,  a  SEND  must  be  transmitted,  which  will  reset 
the  break  bit  and  allow  any  data  in  the  H6070  for  the  9000  to  be  sent. 

(3)  -Any  time  after  the  "#RDYBK"  message  has  been  send  AND  before  any 

"DISCONNECT"  or  "TERMINATE"  message  AND  when  the  "BREAK"  bit  is  not  set,  any 
data  in  the  H6070  for  the  9000  is  sent.  No  request  for  input  is  made. 

e.  Wait  Sequence 

(1)  9000  sends  a  "WAIT"  INFORMATION  message  to  the  355. 

(Ref  B3b(l) 

(2)  355  waits  7  seconds  and  retransmits  the  last  block  it  sent. 

(3)  At  this  point  the  9000  can  send  another  "WAIT"  reinitiating  this 

sequence.  This  can  be  repeated  for  up  to  15  minutes  (or  30  minutes  if  so  sent 

by  the  6070  program!  before  the  355  sends  a  "READY  FOR  DISCONNECT"  message  to  the 
9000. 

(Ref  B5a(6)) 

(4)  The  9000  must  answer  with  a  "READY  FOR  DISCONNECT"  Ref  B5a(6) 
or  "NO  INSTRUCTION"  Ref  B5a(l)  service  message. 


Terminate  or  Disconnecn  Sequence. 


(1)  "TERMINATE"  issued  from  355. 

(a)  355  sends  "TERMINATE"  SERVICE  message  to  QQOO. 

Ref  B5b(2) 

(b)  9000  sends  "NO  INSTRUCTION"  SERVICE  message  to  355. 

Ref  B5a(l) 

(2)  "DISCONNECT"  issued  from  9000. 

(a)  9000  sends  "READY  FOR  DISCONNECT"  SERVICE  msg  to  355. 
Ref  B5a(5) 

(b)  355  responds  with  "READY  FOR  DISCONNECT"  SERVICE 
Ref  B5a(5) 

message  to  9000 

-or- 

9000  sends  "DISCONNECT"  SERVICE  message  to  355. 

Ref  B5a(7) 

The  355  drops  the  line.  No  response. 

(3)  "DISCONNECT"  issued  from  355. 

(a)  355  sends  a  "SPECIAL  CONTROL  RECORD"  message  indicating 
the  reason  for  disconnect.  Ref  B4a(5),  with  message  code  in  "TEXT"  area 
place  of  $*$DACFQRTOS . 

(b)  9000  responds  with  "NO  REQUEST"  INF0R.MATI0N  message. 
(Ref  B3a(l)  with  no  "TEXT"  data. 

(c)  355  sends  a  "READY  FOR  DISCONNECT"  SERVICE  message  to 

9000. 

Ref  B5a(5) 

(d)  9000  must  respond  with  either  a  "READY  FOR  DISCONNECT," 


in 


Ref  B5a(5),  or  "NO  INSTRUCTION,"  Ref  35a(l),  SERVICE  message  to  355. 


-or- 


(e)  355  sends  "DISCONNECT"  SERVICE  message  no  9000. 

Ref  B5a(7) 

(£)  9000  disconnects,  no  response- 

4.  During  the  transmission  of  a  "message"  (BLOCK-ETB,  BLOCK-ETB ,  BLOCK-ETB, 
BLOCK-ETX) ,  if  the  "ETX"  block  has  not  been  ACKED  by  the  355  and  a  disconnect 
or  terminate  occurs,  the  entire  message  must  be  resent  when  the  DAC  mode  is 
resumed.  The  DAC  mode  is  resumed  by  the  "START  SEQUENCE." 
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0  FSD  TO  FRD/ICD 
0  FRO  to  FSD 
0  ICD  TO  FSD 


PREFACE 


This  document  contains  three  matrices;  Functional  Statement  Document  (FSD) 
mapped  to  the  Functional  Requirements  Description  (FRD)  and  the  Interface 
Control  Document  (ICD),  FRD  mapped  to  the  FSD,  and  ICD  mapped  to  the  FSD. 

The  FSD  to  FRD/ICD  matrix  demonstrates  that  the  validated  functional 
requirements  documented  in  the  three  volumes  of  the  FSD  (Section  I  -  Base 
Level  Functions,  Section  II  -  ASC  Residual  Functions,  and  Section  III  - 
Network  Interface  Functions)  are  incorporated,  where  they  are  incorporated  and 
whether  they  are  IOC  or  post  IOC  requirements. 

The  FRD  to  FSD  and  ICD  to  FSD  matrices  indicate  the  FSD  source  of  the 
paragraph  where  appropriate,  thus  it  highlights  those  paragraphs  not  having  an 
FSD  source,  and  whether  the  paragraph  is  applicable  at  IOC  or  post  IOC. 

The  FSD  to  FRD/ICD  matrix  has  six  columns:  the  first  is  the  FSD  function 
in  order  from  all  three  volumes;  the  second  designates  which  volume  of  the 
FSD,  I  for  Base  Level  Functions,  II  for  ASC  Residual  Functions,  and  III  for 
Network  Interface  Functions;  the  third  indicates  Y  for  required  at  Initial 
Operational  Capability  (IOC,  circa  1987)  and  P  for  postulated  post-IOC;  the 
fourth  indicates  which  document  the  FSD  function  has  been  mapped  to  FRD  for 
Functional  Requirements  Description  and  ICD  for  Interface  Control  Document; 
the  fifth  designates  the  paragraph;  and  the  sixth  the  page  number  where  the 
FSD  function  has  been  mapped. 

The  FRD  to  FSD  and  ICD  to  FSD  matrices  have  five  columns:  the  first  is 
the  paragraph  of  either  the  FRD  or  ICD;  the  second  indicates  Y  for  required  at 
IOC  and  P  for  postulated  post-IOC;  the  third  is  the  paragraph  title;  the 
fourth  is  the  page  number  of  the  paragraph;  and  the  fifth  is  the  FSD  function 
which  pertains  to  the  paragraph. 
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3-19 

3.4,  3.9 

3.2.1 .2.1 .2 

Y 

Message  Validation 

3-19 

3.3,  9.0,  II. 9. 3 

3.2.1 .2.1 .3 

Y 

Security  Validation 

3-20 

3.0,  27.9, 

II. 27. 9 

3.2.1 .2.1 .4 

Y 

Error  Processing 

3-20 

3.0,  19.1 ,  27.4 

3.2.1 .2.2 

Y 

Input  Messaae  Processing 
(Terminal] 

3-20 

3.3 

3.2.1 .2.2.1 

Y 

Message  and  Format  Identification 

3-29 

3.3,  9.0 

3.2.1 .2.2.2 

Y 

Message  Validation 

3-29 

3.3,  9.0,  II. 9. 3 

CO  CO 
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3.2.1 .2.2.3 

Y 

Security  Validation 

3-29 

3.0,  27.9, 

II. 27. 9 

3.2.1 .2.2.4 

Y 

Error  Processing 

3-29 

3.0,  19.1 ,  27.4, 
27.6 

3.2.1 .2.2.5 

Y 

Message  Editing  and  Preparation 

Service  (MEPS) 

3-30 

24.0, 

III. 29.0 

3.2.1 .2.2.6 

Y 

Plain  Language  Address  (PLA)  to  Routing 
Indicator  (RI)  Assignment 

3-30 

13.0 

3.2.1 .2. 2. 6.1 

Y 

Formulation  of  Plain  Language  Addresses 

3-30 

13.2 

3.2.1 .2. 2. 6. 2 

Y 

Use  of  Plain  Language  Addresses 

3-30 

13.1 ,  13.3,  27.5 

3.2.1 .2. 2. 6.3 

Y 

Automated  PLA  Directory  Maintenance 

3-31 

13.2,  26.0,  27.5 

3.2.1 .2. 2. 6.4 

Y 

PLA  Directory  Files 

3-32 

13.1 

3.2.1 .2. 2. 6. 5 

Y 

File  Maintenance 

3-32 

13.2,  II. 13. 4, 
26.0,  27.5, 

3.2.1 .2. 2. 6. 6 

Y 

Data  Base  Sizing  for  PL/'; 

3-32 

13.0 

3.2.1 .2.3 

Y 

Input  Message  Processing 
( Network ) 

3-33 

III. 29.0 

3.2.1 .2.3.1 

Y 

Message  and  Format  Identification 

3-33 

3.3,  3.8,  9.0, 
III. 29. 3 

3.2.1 .2.3.2 

Y 

Message  Validation 

3-33 

3.3,  9.0,  II. 9.3 

3.2.1 .2.3.3 

Y 

Security  Validation 

3-33 

3.0,  27.9, 

II. 27. 9 

3.2.1 .2.3.4 

Y 

Error  Processing 

3-33 

3.0,  19.1 ,  27.4, 

3. 2. 1.2. 3. 5 

Y 

Looping  Protection 

3-33 

3.8,  III. 29. 3 

3.2.1  .3 

Y 

Routing 

3-34 

6.0,  13.0, 

III. 29.0 

3.2.1 .3.1 

Y 

Routing  Parameters 

3-34 

3.5 

3.2.1 .3.2 

Y 

Routing  Determination 

3-34 

22.0 

3.2.1 .3.3 

Y 

Special  Routing  Considerations 

3-34 

See  3.2.1 .3.3.1 
thru  3.2.1 .3.3.3 
Bel  ow 

3.2.1 .3.3.1 

Y 

Collective  Routing 

3-34 

3.3,  6.0, 

II. 6. 2,  13.1 

3.2.1 .3.3.2 

Y 

CRITIC  Routing 

3-36 

3.3,  4.1 ,  II. 4. 3 

3.2.1 .3.3.3 

Y 

Multiple  Addressed  Messages 

3-36 

6.0,  II. 6.1 

3.2.1 .4 

Y 

Output  Message  Processing 

3-36 

See  3.2.1 .4.1 
and  3.2.1 .4.2 
Below 

3.2.1 .4.1 

Y 

Network  Outgoing  Message  Processing 

3-36 

III. 29.0 

3.2.1 .4.2 

Y 

Terminating  Message  Processing 

3-37 

See  3. 2. 1.4. 2.1 
and  3. 2. 1.4. 2. 2 
Bel  ow 

3.2.1 .4.2.1 

Y 

f'lessage  Distribution  Function 

3-37 

11.0,  14.0 

3. 2. 1.4. 2. 1.1 

Y 

Distribution  Determination  Parameters 

3-37 

11.1, 

11.5-11.10,  14.0 

3.2.1 .4.2.1 .2 

Y 

Distribution  Determination 

3-38 

11.5-11.10,  14.0 

CO  CO 
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3.2.1 .4.2.1 .2.1 

Y 

Comeback-Copies  of  Messages 

3-38 

14.1 

3. 2. 1.4. 2. 1.2. 2 

Y 

Multiple  Copy  Determination 

3-38 

11.2,  14.0 

3. 2. 1.4. 2. 2 

Y 

Message  Delivery 

3-38 

11.4 

3. 2. 1.4. 2. 2.1 

Y 

Message  Delivery  Parameters 

3-40 

11.4,  11.5-11.10 

’.2.1 .4. 2. 2. 2 

Y 

Message  Delivery  Determination 

3-40 

11.4,  11.5-11.10 

3. 2. 1.4. 2. 2. 3 

Y 

Security  Validation 

3-43 

3.7,  II. 9. 3 

3.2.1 .4. 2. 2. 4 

Y 

Format  Conversion 

3-43 

9.0 

3. 2. 1.4. 2. 2. 5 

Y 

Media  Conversion 

3-43 

7.0,  7.1 

3.2.1 .4. 2. 2. 6 

Y 

Message  Media  Services 

3-43 

11.0,  11.1 

3. 2. 1.4. 2. 2. 6.1 

Y 

Di stribution  Identi fi cation 

3-43 

11.3 

3.2.1 .4. 2. 2. 6. 2 

Y 

Message  Identification 

3-43 

12.2 

3.2.1 .4. 2. 2. 6. 3 

Y 

Edi ti ng 

3-44 

12.2 

3.2.1 .4. 2. 2. 6. 4 

Y 

Print  Expansion  of  Reports 

3-44 

12.3 

3.2.1 .4. 2. 2. 6. 5 

Y 

Classification  Display 

3-44 

II.27.9d 

3.2.1 .4. 2. 2. 6. 6 

Y 

Special  Print  Out  Requirements 

3-44 

App.  12A 

3.2.1 .4. 2. 2. 7 

Y 

Data  Pattern  Delivery  Processing 

3-44 

12.1 

3.2.1 .4. 2. 2. 7.1 

Y 

Data  Pattern  Delivery 

3-45 

12.1 

3. 2. 1.4. 2. 2. 7. 2 

Y 

Data  Pattern  Sections 

3-45 

12.1 

3.2.1 .4.2.3 

Y 

Output  RI  Classmarking 

3-45 

II. 6.1 

3. 2. 1.5 

Message  Processing  Control 

3-46 

Title  Only 

3.2.1 .5.1 

Y 

Precedence  Processing 

3-46 

4.0,  II. 4. 3 

3. 2. 1.5. 2 

Y 

Message  Preemption 

3-46 

5.0,  5.1,  5.2 

’.2.1 .5.3 

Y 

Automation  Assisted  Traffic  Management 

3-46 

20.0 

3. 2. 1.5. 3.1 

Y 

Traffic  Loading 

3-47 

16.3,  20.3 

3. 2. 1.5. 3. 2 

Y 

Message  Timing  and  Overdue  Notification 

3-47 

3.2.b,  16.2, 

27.3,  27.4 

3. 2. 1.5. 3. 3 

Y 

Intercept  Processing 

3-48 

4.0,  20.1, 

3. 2. 1.5. 4 

Y 

Overflow  Protection 

3-48 

4.0,  18.0, 

3.2.1 .5.5 

Y 

Alternate  Routing 

3-48 

22.0,  II. 22.0 

3. 2. 1.5. 6 

Y 

Queue  Management 

3-49 

20.3,  27.1.e 

3.2.1 .5.7 

Y 

Automated  Routing/Distribution  File 

3-49 

26.0 

Mai ntenance 

3. 2. 1.5. 8 

Y 

Service  Messages 

3-49 

19.0 

3. 2. 1.5. 8.1 

Y 

System  Generated  Service  Messages 

3-49 

8.1,  19.1,  27.7, 
II. 4. 3,  II. 19.1 

3. 2. 1.5. 8. 2 

Y 

Automated  Processing  of  Service  Messages 

3-50 

15.0,  19.2,  21.0 

3. 2. 1.5. 8. 3 

Y 

Manual  Processing  of  Service  Messages 

3-50 

19.3,  25.0 

3. 2. 1.6 

Y 

Accountability  and  Recordkeeping 

3-50 

3.2 

3. 2. 1.6.1 

Y 

Message  Accountability 

3-50 

3. 2. a,  3.2.b, 
3.9,  8.3 

3.2.1 .6.2 

Y 

History  Logs  and  Files 

3-51 

8.0,  8.2, 

27.1.d,  II. 8.1, 

II. 27. 9. b,  App. 
8A 

3.2.1 .6.2.1 

Y 

Incoming  and  Outgoing  Journal  Entries  - 

3-51 

3.2,  8.2, 

Y 

System  Status  Information 

16.3,  27.3, 

II. 16.3 

3. 2. 1.6. 2. 2 

Y 

Reference  Entries 

3-51 

8.2,  8.3 

3. 2. 1.6. 3 

Y 

History  Data  Interrogation 

3-54 

20.2 

3.2.1 .7 

Y 

Message  Search,  Retrieval,  Readdressal 

3-54 

8.1,  15.0, 

and  Retransmission 

21.0 

3. 2. 1.7.1 

Y 

Message  Data  Search 

3-54 

16.1,  21.0, 

II. 16.6 
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3.3.3 

Y 

Configuration  Monitoring  and  Control 

3-68 

22.0,  27.2, 

II. 27. 7b 

3. 3. 3.1 

Y 

Activations/Deactivations  of 

3-68 

26.0,  27.2, 

Subscribers  and  Transmission  Links 

II. 27. 7b 

3. 3. 3. 2 

Y 

Subscriber  and  DON  Access  Line  Reroute 

3-68 

27.2, 

and  Restoral 

II. 27. 7b 

3. 3. 3. 3 

Y 

Network  Configuration  Engineering 

3-69 

16.0,  II. 28.0 

3.3.4 

Y 

Traffic  Flow  and  Routing  Control 

3-69 

20.0,  II. 28.0 

3. 3.4.1 

Y 

Traffic  Flow  Control 

3-69 

18.0,  20.0,  20.1 

3. 3. 4. 2 

Y 

Routing  Control 

3-70 

22.0 

3.3.5 

Y 

Status  Monitoring  and  Performance 

3-70 

16.3 

Assessment 

^.3.5.1 

Y 

Status  Monitoring 

3-71 

27.7,  II. 27. 7 

3.3. 5.1 .1 

I -S/A  AMPE  Status  Monitoring 

3-71 

Title  Only 

3. 3. 4. 1.1.1 

Y 

Impairment/Outage  Condition 

3-71 

27.7,  II. 27. 7 

3. 3.5.1 .1 .2 

Y 

Equipment  Status 

3-71 

27.7,  II. 27. 7 

3. 3. 5.1 .1 .3 

Y 

Hazardous  Condition 

3-71 

27.7,  II. 27. 7 

3. 3. 5.1 .2 

Y 

Subscriber  and  DDN  Access  Line 

3-71 

27.4,  27.7, 

Impai rment/Outage 

II. 27. 7 

3.3. 5.1 .3 

Y 

Equipment  Status 

3-72 

27.7,  II. 27. 7 

3. 3. 5. 1.4 

Y 

Subnetwork  Status 

3-72 

16.0,  27.0, 

II. 28.0 

3. 3. 5. 2 

Y 

Performance  Assessment 

3-72 

16.0,  27.4 

3. 3. 5. 3 

Y 

Traffic  Header  Statistics 

3-72 

16.0,  II. 16.0 

3. 3. 5. 3.1 

Y 

Traffic  Statistics  Processing 

3-72 

16.1 

3. 3. 5. 3. 1.1 

Y 

Total  Traffic  Volume 

3-72 

16.1 

3. 3. 5. 3.1  .2 

Y 

Busy  Period  Traffic  Volume 

3-73 

16.1,  II. 16. 3 

3. 3. 5. 3. 1.3 

Y 

Multiple  Addressing  Factor 

3-73 

★ 

3. 3. 5. 3. 2 

Y 

Speed  of  Service  Data 

3-73 

II.28.1b(l  )(b) 

3. 3. 5. 3. 2.1 

Y 

Network  Delay 

3-73 

II.28.1b(l )(b) 

3. 3. 5. 3. 2. 2 

Y 

SOS  &  Network  Delay  Matrix 

3-73 

II.28.1b(1 )(b) 

3. 3. 5. 3. 3 

Y 

Message  Length 

3-73 

16.1 

3. 3. 5. 3.4 

Y 

I -S/A  AMPE  Load  and  Throughput  Data 

3-76 

16.0 

3. 3. 5. 3. 5 

Y 

Access  Line  Backlog  Data 

3-76 

16.3,  27.4, 

II. 16. 3 

3.3.6 

Reporting 

3-76 

Title  Only 

3. 3. 6.1 

Y 

DCAC  310-55-1  Reporting 

3-76 

II. 16. 5 

3. 3. 6. 2 

Y 

MC  Reporting 

3-76 

II. 16. 5,  II. 28.0 

3. 3. 6. 3 

Y 

Subscriber  Reporting 

3-76 

16.3 

3. 3. 6.4 

Y 

DCS  Message  Quality  Control 

3-77 

II. 16.5 

3.3.7 

Y 

Fault  Isolation  and  Correction 

3-77 

27.7,  II. 27. 7 

3. 3. 7.1 

Y 

Circuit  Configuration  Data  Base 

3-77 

II. 27. 7 

3. 3. 7. 2 

Y 

Circuit  Quality  Monitor 

3-78 

27.7,  11.27. 7 

3. 3. 7. 3 

Y 

Remote  Access  to  Circuit  Segments 

3-78 

27.7 
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3. 3. 7.4 

Y 

Automatic  Fault  Isolation 

3-78 

27.7,  11.27. 7 

3. 3. 7. 5 

Y 

Semi -Automated  Switching 

3-78 

27.7,  II. 27. 7 

3. 3. 7. 5.1 

Y 

Red/Black  Isolation 

3-79 

II. 27. 9. C 

3. 3. 7. 5. 2 

Y 

Subscriber  Community  Separation 

3-79 

27.9.3 

3. 3. 7. 6 

Y 

Interface  with  Technical  Control 

3-79 

11.27. 7 

3.3.8 

Y 

Billing  Data 

3-79 

16.0,  16.1  ,  16.2 

3.3.9 

Y 

I-S/A  AMPE  Internal  Control 

3-79 

Title  Only 

3. 3. 9.1 

Y 

Operator  Control  Function 

3-79 

27.2 

3. 3. 9. 2 

Y 

Failure  Recovery  Management 

3-80 

27.1 

3. 3. 9. 2.1 

Y 

Automatic  Recovery 

3-81 

27.1  .a 

3. 3. 9. 2. 2 

Y 

Manual  Recovery 

3-81 

27.1.b 

3. 3. 9. 3 

Y 

Data  Base  Management 

3-81 

26.0 

3.4 

I-S/A  AMPE  Security 

3-84 

TITLE  ONLY 

3.4.1 

Y 

General 

3-84 

27.9,  II. 28. 2 

3.4.2 

Y 

DSSCS/GENSER  Integration 

3-84 

27.9 

3.4.3 

Y 

Security  Certification 

3-84 

27.9,  11.28. 2 

3.4.4 

Y 

Cryptographic  Security 

3-85 

II. 27. 9c 

3.5 

Y 

Performance  Requirements 

3-86 

See  3.5.1  thru 
3.5.6  Below 

3.5.1 

Y 

Traffic  Processing 

3-86 

III. 29.0 

3.5.1 .1 

Y 

Formal  Message  Service  Traffic 
Characteristics  and  Traffic  Loads 

3-86 

II. 28.1 ,  III. 29.0 

3.5.1 .1 

Y 

Input  Traffic  Processing  Capability 

3-86 

II. 28.1 

3.5.1 .2 

Y 

Output  Traffic  Processing  Capability 

3-91 

II. 28.1 

3. 5. 1.2 

Y 

Throughput  Processing  Capability 

3-91 

II. 28.1 

3.5.1 .3 

Y 

Traffic  Processing  Delays 

3-91 

II. 28.1 

3.5.1 .3.1 

Y 

Formal  Message  Service  Processing  Delays 

3-91 

II. 28.1 

3.5.1 .3.2 

Y 

Data  Transactions  to  the  IAS  Network 

3-92 

11.28. 1 

3.5.2 

Y 

Connection  Service 

3-93 

II. 28.1b(l  ), 

III.  29. 4 

3.5.3 

Y 

Storage  Requirements 

3-94 

8.1  ,  13.0,  17.0, 
III. 29. 2 

3. 5. 3.1 

Y 

Plain  Language  Address  (PLA)  to  RI  Table 

3-94 

13.0 

3. 5. 3. 2 

Y 

RI  to  Logical  Address  Table 

3-94 

III. 29. 2 

3. 5. 3. 3 

Y 

On-Line  FMS  Storage 

3-94 

8.1,  17.0 

3. 5. 3. 4 

Y 

Search  and  Retrieval  Access  Times 

3-94 

21 .0 

3. 5. 3. 5 

Y 

General  Storage  Requirements 

3-94 

17.0 

3.5.4 

Y 

Processing  Error  Rates 

3-95 

3.1  , 

II.28.1b(l )(a)3 
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3.5.4. 1 

Y 

Undetected  Error  Rate 

3-95 

3.1, 

II.28.1b(l  )(a)3 

3.5.5 

Y 

Availabil ity 

3-95 

II.28.1b(l  )(a)2 

3. 5. 5.1 

Y 

Recovery 

3-95 

27.1 

3.5.6 

Y 

Degraded  Operation 

3-96 

27.1 

3.6 

Y 

Requirements  for  Software  and  Firmware 

3-97 

1 1. 28.1 

Development 

3.6.1 

Y 

Modifications  to  MIL-STD-1679 

3-97 

II. 28. lad  ) 

3.6.2 

Y 

Software  and  Firmware  Management 

3-98 

II. 28. lad  ) 

3.6.3 

Y 

Programming  Requirements 

3-99 

II. 28. lad  ) 

3.6.4 

Y 

Documentation  Requirements 

3-99 

II. 28. lad  ) 

3.7 

Hardware  System  Requirements 

3-100 

Title  Only 

3.7.1 

Y 

Hardware  Definition 

3-100 

27.4,  27.7, 

II. 27. 7,  III. 29.0 

3.7.2 

Y 

Modularity 

3-100 

II.28.1a(2) 

3.7.2. 1 

Y 

Reliability  Through  Modularity 

3-100 

1 1. 28. la 

3. 7. 2. 2 

Y 

Sizi ng 

3-100 

17.0,  II. 28. la 

3.7.3 

Y 

Memory 

3-101 

17.0 

3. 7. 3.1 

Y 

In-Transit  Storage 

3-101 

17.0 

3. 7. 3. 2 

Y 

Message  Storage  for  Retrieval 

3-101 

8.1  ,  21 .0 

3. 7. 3. 3 

Y 

Memory  Access 

3-101 

27.9.2 

3.7.4 

Y 

Fault  Isolation  and  Connection 

Capabil i ty 

3-101 

27.7,  II. 27. 7 

3. 7. 4.1 

Y 

Connection  Capability 

3-101 

27.7,  II. 27. 7 

3. 7. 4. 2 

Y 

Testing 

3-102 

27.7,  II. 27. 7 

3. 7.4. 3 

Y 

Reporting 

3-102 

16.4,  II. 16. 5 

3.7.5 

Y 

Operational  Characteristics 

3-102 

See  3. 7. 6.1  thru 

3. 7. 6. 7  Below 

3. 7. 5.1 

Y 

Availabil ity 

3-102 

II.28.1bd  )(a) 

3. 7. 5. 2 

Y 

Rel iabil i ty 

3-103 

27.1,  27.2 

3. 7. 5.3 

Y 

Maintainabil ity 

3-103 

II. 28.1 

3. 7. 5.4 

Y 

Interrupt  Structure 

3-103 

27.9.2 

3. 7. 5. 5 

Y 

Instruction  Set 

3-103 

* 

3. 7.5.6 

Y 

Instructions  in  Hardware 

3-103 

* 

3.8 

Design  and  Development 

3-104 

Title  Only 

3.8.1 

Y 

Modul ari ty 

3-104 

II. 28. la 

1.8.2 

Y 

Software  Design 

3-104 

II. 28. lad  ) 

3.8.3 

Y 

Hardware  Design 

3-104 

II.28.1a(2) 

3.8.4 

Y 

Cornmonal  ity /Standardization 

3-104 

★ 

3.8.5 

Y 

Human  Performance/Human  Engineering 

3-105 

★ 

3.9 

Y 

Maintainability  and  Logistics 

3-105 

★ 

3.9.1 

Y 

Maintenance 

3-105 

★ 

3.9.2 

Y 

Maintenance  Concept 

3-106 

★ 

3.10 

V 

Precedence 

3-106 

★ 

3.10.1 

Y 

Securi ty 

3-106 

10.0 

3.10.2 

Y 

Flexibility 

3-106 

II.28.1a(2) 

3.10.3 

Y 

Performance 

3-106 

13.0,  14.0, 

18.0,  19.0 

3.11 

Y 

Government  Furnished  Property  (GFP) 

3-106 

Title  Only 

3.11.1 

Y 

Design  Assistance 

3-106 

★ 

3.11.2 

Y 

Hardware  and  Software 

3-107 

★ 
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3.12 

N/A 

Pre-planned  Product  Improvement 

3-1C7 

3.12.1 

N/A 

Pre-planned  Product  Improvement 
Implementation 

3-107 

★ 

3.12.2 

P 

Additional  I -S/A  AMPE  Services 

3-107 

★ 

3.12.3 

P 

Data  Path  Requests 

3-1 08 

29.4b 

3.12.4 

P 

Preamble  Format 

3-109 

9.1 

3.12.5 

P 

Routing  Table  Updates 

3-109 

★ 

3.12.6 

P 

DSSCS  and  GENSER  Consolidation 

3-109 

10.0 

3.13 

Trai ni ng 

3-109 

★ 

4.0 

Y 

QUALITY  ASSURANCE  PROVISIONS 

4-1 

★ 

4.1 

Y 

Contractor  Configuration/Development 
Reviews 

4-1 

★ 

4.1.1 

Y 

Configuration  Management 

4-1 

★ 

4. 1.1.1 

Y 

Configuration  Management  Baselines 

4-2 

★ 

4. 1.1.2 

Y 

Engineering  Change  Proposals 

4-2 

★ 

4.2 

Y 

Contractor  Validation  Testing 

4-2 

II. 28. 2 

4.2.1 

Y 
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